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FOREWORD 


This final report of the IUS/Tug Orbital Operations and Mission Study was 
prepared for the National Aeronautics and Space Administration, George C. 
Marshall Space Flight Center by the IBM Corporation in accordance with Contract 
NAS8-31009. 


The study effort described herein was conducted under the direction of NASA 
Contract Officer's Representative (COR), Mr. Sidney P. Saucier. This report 
was prepared by the IBM Corporation, Federal Systems Division, Huntsville, 
Alabama, under the direction of Mr. Roy E. Day, IBM Study Manager. Technical 
support was provided to IBM by the Philco-Ford Corporation, Western Development 
Laboratories Division, Palo Alto, California, under the direction of Dr. 

W. E. Waters, Philco-Ford Study Manager. The study results were developed 
during the period from June, 1974, through February, 1975, with the final 
report being distributed in May, 1975. 

The results of this study have been documented in five separate volumes. 


Volume I 
Volume II 
Volume III 
Volume IV 
Volume V 


Executive Summary 
IUS Operations 
Tug Operations 
Project Planning Data 
Cost Estimates 


Questions and comments regarding this study activity should be directed to: 


Sidney P. Saucier, COR 
NASA Marshall Space Flight Center 
Attention: PF-02-E 

Huntsville, Alabama 35812 
Telephone: (205) 4532795 


R. E. Day, Study Manager 

International Business Machines Corporation 

Attention: 53-F03 

Huntsville, Alabama 35805 

Telephone: (205) 837-4000, extension 2636 
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INTRODUCTION 


This volume contains the background data and study results for the Interim 
Upper Stage (IUS) operations phase of the IUS/Tug Orbital Operations and Mission 
Support Study. For the purposes of this final report, the contract name has • 
been shortened to Orbital Operations Study. This volume provides the basic 
analysis results and data for the Transition Phase Analysis (Phase 4) which is 
the transition from IUS to Tug operations, contained in Volume III, and for the 
IUS costing which is detailed in Volume V. All IUS data, except closing details, 
are included in this volume. 

1 . 1 BACKGROUND 

The Space Transportation. System will include a propulsive stage that is carried 
to low earth orbit by the Space Shuttle (Orbiter). The Interim Upper Stage will 
be developed by the Department of Defense (DoD) and will be a modification to an 
existing space vehicle for use by both NASA and DoD from 1981 until a more 
capable Space Tug will be operational in 1984. The Expendable IUS may also be 
used for selected missions after 1984. The IUS is a storable propellant vehicle . 
defined by NASA as a baseline for this study effort. It is an existing vehicle 
modified to meet the IUS requirements. Presently, DoD study contracts are being 
performed to better define the IUS requirements and associated designs, which 
will lead to a selection of an IUS vehicle. 

1.2 PURPOSE AND. SCOPE 

The basic purpose of this phase of the Orbital Operations Study was to develop 
IUS operational concepts, an IUS Baseline Operations Plan, and to provide cost 
estimates for IUS operations. An overall study approach for the IUS Operations 
Phase is shown in Figure 1.2. 0-1. The basic IUS study approach was to compile 
and evaluate baseline concepts, definitions and system, and to use that data as 
a basis for the IUS operations phase definition, analysis and costing analysis. 

The operational analysis led to the IUS operational concepts and the IUS Baseline 
Operations Plan. In addition, special emphasis trades and analyses were performed. 

Both expendable and reusable IUS configurations were analyzed during the IBM 
study and two autonomy levels were specified for each configuration. During the 
latter phases of this study, a basically autonomous expendable IUS was baselined 
for major emphasis for the remainder of the study effort and most of the de- 
tailed concepts and analyses assumed this configuration as the baseline. The 
reusable IUS and the two autonomy levels were developed early in the study to 
provide a basis for preliminary costing and operations evaluation. Transition 
phase costing was based on the expendable IUS configuration and operations. 

The major emphasis items for the IUS study was on-orbit operations and interfaces 
with the Orbiter, the Tracking and Data Relay Satellites and ground station 
support capability analysis, and flight control center sizing to support the IUS 
operations. 
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Figure 1. 2.0-1. I US/Tug Overall Study Approach 







1 .3 DOCUMENT OUTLINE 


The following paragraphs give a hrief overview of the type of information 
continued in each of the sections included in this volume: 

• Section 2.0 - gives a summary of the IUS operational and interface 
requirements with emphasis on the on-orbit checkout requirements, 

Orbiter interface and operational requirements, and safety requirements. 

• Section 3.0 - gives a brief summary of the three types of reference 
missions based for the IUS and details for the mission functional 
flows and timelines derived for the IUS missions. 

• Section 4.0 - gives an overview of the IUS subsystems, with emphasis 
on component description and operations which would be used in the 
flight operations analysis. 

• Section 5.0 - provides the operational interfaces definitions for the 
IUS interface with the Orbiter, the Spacecraft, Ground Support Equipment, 
and the IUS ground control center, with emphasis on the IUS/Orbiter 
operational interfaces, and Caution & Warning parameter definitions. 

• Section 6.0 - gives a detailed discussion of the Expendable IUS on-orbit 
predeploy and post deploy operations prior to the EIUS first burn. Items 
emphasized include checkout philosophy, activation and monitoring 
functions, and Orbiter software impacts to support the EIUS. 

• Section 7.0 - discusses the operations related to the Spacecraft deploy- 
ment by the IUS. Major emphasis is the discussion of IUS support during 
the deployment operations. 

• Section 8.0 - gives an overview of the STDN and TDRSS characteristics 
and data flow, an analysis of the communication interface support 
available for IUS missions, discussion of the IUS, Spacecraft, and 
Orbiter operations center interfaces and operations, and an analysis of 
potential problem area in the design of a new operations center. 

• Section 9.0 - is the IUS Baseline Operations Plan. It contains the 
mission plan overview, the functional organization for flight control 
and flight support personnel, the mission control group functions and 
definitions, the ground and flight support hardware and software de- 
scriptions and summarizes the IUS cost estimates made during the study.' 

• Section 10.0 - gives an overview of potential problem areas or impact 
areas defined during the study effort. 

• Section 11.0 - gives the references used to aid in the development of 
Volume II. 
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IUS REQUIREMENTS SUMMARY 

The IUS operations, safety and interface requirements are included in Reference 
1 ("Basic IUS System Requirements - Part I", SR-IUS-100) and Reference 2 
("IUS System Detail Safety Requirements", Appendix IV to SR-IUS-100). The 
requirements from the above references which were used as the basis for interface 
deployment (checkout) operations are summarized in this section. The correspond- 
ing paragraph number for the above references are given in parenthesis. No 
major operational discrepancies .for the IUS were noted except as discussed in 
Section 6.2.1 . 

2.1 IUS OPERATIONS AND INTERFACE SYSTEM REQUIREMENTS 

This section gives a summary of the pertinent IUS system operation and inter- 
face requirements from Reference 1. 

SAFETY STATUS AND CONTROL OF IUS/SPACECRAFT (3.1.8) 

The IUS System shall provide data to the Orbiter concerning the status, or 
condition, of safety critical IUS and spacecraft functions. Provisions shall 
also be made for Orbiter control of those safety critical functions. 

SYSTEM VERIFICATION (3.1.9) 

The IUS System shall verify the ability of the IUS to perform its mission at 
a time after Orbiter ascent but prior to deployment. The data transmission 
to the Orbiter shall be compatible with the interface per Paragraph 4. 1.3. 2. 

The IUS System' shall accommodate a limited closed loop checkout/verification 
of the spacecraft by the Orbiter prior to separation of the spacecraft and stage 
from the Orbiter. The limited go/no-go checkout will be conducted independent 
of the IUS avionics subsystems. 

DEPLOYMENT - UPPER STAGE (3.2.1) 

The IUS with attached spacecrafts (s) shall be capable of being deployed from the 
Orbiter within TBD hours after insertion into the nominal Orbiter parking orbit. 

TELEMETRY, TRACKING AND COMMAND (TT&C) (3.2.6) 

The TT&C subsystem shall be compatible with the Orbiter and with the SGLS/STDN 
ground stations. 

TELEMETRY - When the telemetry downlink is addressed to either the 
visible Orbiter, v or to visible ground stations, the effective radiated 
power shall be adequate to provide a Bit Error Rate (BER) of 10“° at the 
receiving station independent of IUS attitude. The period over which the 
telemetry downlink shall be available is from Orbiter/IUS - spacecraft 
deployment until the time of completion of the IUS/Spacecraft separation 
maneuver. 

TRACKING - The SGLS/STDN compatible radio links shall be capable of 
coherent turn-around of the PRN modulation used to determine range and 
range rate at the AFSCF/STDN ground stations. 
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COMMAND - The IUS shall be able to accept commands from the Orbiter and 
the SGLS/STDN ground stations. The table of commands shall be adequate 
to provide the necessary safety and executive controls of the IUS. The 
command reception capability shall be available at all, and any, orienta- 
tion attitudes. 

SAFETY STATUS VERIFICATION (3.2.7) 

The IUS shall provide to the Orbiter that data during deployment, and while in 
the near vicinity of the Orbiter, that permits evaluation of the status, or 
condition, of safety critical functions. The transmission method shall be 
compatible with Orbiter systems and have an error rate of 10 -6 at ranges of 
0 to 20 nautical miles. The capability shall be available at all orientation 
attitudes . 

ORIENTATION (3.2.9) 

During unpowered coasting flight modes, the IUS shall provide the capability 
for attitude hold, preferential orientation, or predetermined roll or any' 
combination of the three maneuvers for the purpose of providing, spacecraft 
thermal control, telemetry transmission, solar array orientation or spacecraft 
deployment. 

TELEMETRY DIPOUTS (3. 2. 9. 1.2) 

Specific orientations to provide satisfactory IUS telemetry transmissions 
shall not be required by the IUS. 

VENTING (4. 1.2. 4) 

The IUS, while in the payload bay, shall be capable of controlled venting of 
fluids and gases as required through the fluid interface connections from the 
IUS to the Orbiter in the veritical and horizontal positions. 

SAFETY STATUS AND CONTROL (4. 1.3.1) 

The IUS shall provide, while in the payload bay, adequate data to establish 
the safety status of the IUS/Spacecraft. The type and handling of the data 
shall be in accordance with Section 5.2. Control of potential hazardous condi- 
tions, as defined in Section 5.2, shall be provided. The data and control 
configuration shall be compatible with the Orbiter. 

IUS DATA AND COMMAND (4. 1.3. 2) 

The IUS shall be compatible with the Orbiter and able to communicate its 
status and receive commands which it may require for status monitoring and 
checkout from the Orbiter while stowed in the payload bay. 

INITIALIZATION AND UPDATE (4. 1.3. 3) 

Orbiter navigation data derived by Doppler techniques from STDN stations 
(NASA) and SGLS stations (DoD) and from ground tracking data (STDN and SGLS) 
through the respective NASA and DoD Orbiter Communication system may be used 
by IUS. For NASA availability of the tracking and Doppler data may be 
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augmented by the use of TDRSS. The accuracies of these update possibilities 
as a function of Orbiter timelines is TBS. 

Control of mechanical alignments of IUS to Orbiter and optical platform 
alignment transfer techniques will not be provided. Selected update means 
for attitude, position, and velocity shall not result in NASA/DoD peculiar 
guidance system mechanizations. 

COMMAND AND CONTROL (4. 2. 3.1) 

The IUS System shall accommodate the transmission of commands from the Orbiter 
to the spacecraft while the spacecraft and stage are attached to the Orbiter. 
Data rates for commands sent to the spacecraft will be compatible with the 
Orbiter. 

The IUS shall provide the capability for sending a spacecraft separation signal 
to the spacecraft/IUS separation system. This single separation signal will 
have to service multiple satellite separation. 

TELEMETRY (4. 2.3. 2) 

The IUS System shall accommodate the transmission of spacecraft telemetry and 
safety data to the Orbiter while the spacecraft and IUS are attached to the 
Orbiter. Spacecraft telemetry will be sent from the spacecraft to the Orbiter 
at rates up to 16 Kbps. 

The IUS shall be capable of transmitting to the ground: (1) state vector and 
attitude data at the transfer orbit injection and final orbit injection of the 
IUS/Spacecraft, and (2) verification of IUS to spacecraft separation event. 

IUS SYSTEM GROUND INTERFACES (4.3) 

The IUS System shall be compatible with Interfacing KSC (Kennedy Space Center) 
facilities and AGE, including items of the Shuttle System and special IUS items 
of AGE and facilities. The IUS System shall also utilize the DoD and NASA 
ground networks. 

IUS IN PAYLOAD BAY (4. 3. 2.1) 

The IUS interfaces with the Orbiter shall be compatible to permit required 
telemetry and command link operation with appropriate SGLS/STDN ground stations. 

IUS OUTSIDE ORBITER (4. 3. 2. 2) 

The telemetry, tracking, and command links between the IUS and the appropriate 
SGLS/STDN ground stations shall be compatible with the operating characteristics 
of those ground stations. The effective radiated power of the downlink 
communications, and the noise figure of the uplink receiving equipment shall be 
adequate to provide the required service within the capabilities of those 
stations. The communication links shall be operative at all orientation 
attitudes of the IUS. 
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SAFETY (5.2) 


The IUS System shall meet the safety requirements of JSC 07700, Vol . XIV, 

Paragraph 11.0, "Safety Assurance for Space Shuttle Payloads", Revision TBD. 

(5.2.2) During launch and on-orbit, the IUS System shall be capable of 

manned safety operation during Shuttle-powered flight, pre-deploy 
checkout, deployment from the Orbiter and post-deploy while still 
in the vicinity of the Orbiter. 

(5.2.4) The IUS System shall be capable of being safed for all Shuttle abort 
and back-out conditions and the interface attachments to the Orbiter 
must be capable of surviving crash design load factors. 

(5.2.5) The IUS System shall be capable of having all safety critical items 
monitored in the Orbiter and by ground link during all phases of 
Shuttle operations, including deployed while still in the vicinity 
of the Orbiter. 

(5.2.6) The IUS System shall be capable of being maintained and/or commanded 
safe at all times when installed in the Orbiter and when deployed in 
the vicinity of the Orbiter. 

2.2 IUS OPERATIONS AND INTERFACE SAFETY REQUIREMENTS 

This section gives the pertinent IUS safety requirements related to IUS 

interfaces and operations summarized from Reference 2. 

GENERAL OPERATIONS (3.1.1) 

• Under all nominal, contingency or emergency operations; (1) no single 
failure of a dynamic system of the IUS System, or (2) no two (2) 
sequential procedural errors shall result in the transmission of an 
accident potential to or from the IUS System and its interfaces 
including flight and ground personnel. 

• No single failure of a dynamic system of the IUS System shall result 
in an accident which jeopardizes the general public/private property, 
or the ecology. 

• Shuttle missions are planned to be terminated if failures occur 
which create a situation where one additional failure can cause 
injury to personnel or loss of Orbiter. Therefore, all dynamic 
systems of the IUS System shall be capable of tolerating at least 
one failure before requiring mission termination. 

• The IUS shall provide at all times such information concerning the 
status or condition of safety critical IUS Systems (audible and 
visual caution and warning) while in the Orbiter bay or near vicinity 
of the Orbiter. Provisions shall be made for Orbiter crew command 
override of these functions for adequate corrective action. Adequate 
redundancy of these systems shall be required. 
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• All safety critical data, displays, and controls shall be capable 
of being verified functional prior to the initiation of the safety 
critical event. 

t Any procedure which, if erronously executed, can cause a hazard 
to the Shuttle shall be identifed as a Safety Critical Procedure. 

• A safe interface between the Shuttle and the IUS, and the IUS and 
its spacecraft shall be maintained under all nominal, contingency, 
and emergency operations of either the Shuttle, the IUS, the IUS 
spacecraft or the IUS support equipment. 

FLIGHT OPERATIONS (3.1.3) 

• Propellant tank pressures shall not be increased to operational 
values until a safe distance from the Orbiter after deployment. 

t The attitude control system of the IUS shall be capable of being 
checked for accuracy by the Orbiter crew before IUS release. 

• IUS propellant tank integrity shall be verified, pressures shall be 
reduced to a manned safety value, and safety critical subsystems shall 
be safed or verified functional before IUS recovery operations begin. 

• IUS attitude control or IUS main engine thrust shall not be used 
for initial separation of the 'IUS to a safe distance from the 
Orhiter. 

PROPULSION (3.2.2) 

• No single operation shall result in a flow of propellant through 
the IUS propulsion system while the IUS is in the Orbiter payload 
bay. 

• Interlocks shall be provided to assure that propulsion systems 

will not be fired while in the Orbiter cargo bay or that propellants 
will not^be dumped in the payload bay. 

• IUS propulsion system start sequence logic status and valve 
positions shall be monitored and message signals shall be provided 
at the Shuttle Data Management Interface. 

• Inadvertant main engine start sequence shall be positively inhibited. 

AVIONICS (SYSTEM) (3.2.3) 

t Message signals from the IUS System shall be provided at the 

Shuttle Data Management System Interface. Measurements shall in- 
clude IUS latched/released indications, deploy mechanism position 
indications, discrete pyrotechnic event indications, sequence logic 
status, valve positions, temperature and pressure measurements, and 
failure indications. This information shall also be available prior 
to recovery. 
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• RF communication capability shall be available between the Orbiter 
and the IUS from command and control functions while separated from 
the Orbiter and up to a separation distance of 20 n mi. 

• Commands affecting safety critical equipment status must have 
associated data transmission to provide a positive functional 
verification. 

• IUS autonomous navigation commands for attitude control and trans- 
lation maneuvers shall be disabled until a safe separation distance 
is achieved. 

ELECTRICAL (3.2.4) 

• Safety critical control circuits shall be capable of being verified. 

• Positive indications of IUS electrical systems shut down status shall 
be provided to the Orbiter flight crew prior to recovery. 

• IUS shall have a means of shutting off its electrical power under 
emergency conditions. 

PYROTECHNIC (3.2.5) 

• Sequence logic and pyrotechnic firing circuits shall be at least 
dual redundant. 
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INTERIM UPPER STAGE (IUS) Q 
MISSION OPERATIONS ANALYSIS O 

The IUS missions consist of delivery of spacecraft to orbits outside the 
performance range of the Shuttle Orbiter. Missions are currently planned in 
the following spacecraft disciplines: Astronomy, High Energy and Solar 

Physics, Atmospheric Physics, Earth Observation, Communication and Navigation, 
and Planetary. Mission sources for this study include NASA, commercial and 
foreign users. This section represents typical sets of IIJS Missions which 
were analyzed to determine operational requirements. 

Two typical mission models were utilized during the study for the years 
1981-1991. These models contained representative payload (Spacecraft) classes, 
flight frequency, and estimated payload weights and dimensions. They were • 
grouped according to destination: (1) sun synchronous, (2) geosynchronous, 

and (3) interplanetary. The two mission models used in this study were (1) 
Space Shuttle Traffic Model, October 1973, and (2) a summary traffic model 
developed by the NASA Tug Task Team during the course of the study. From the 
mission models, the most dense launch year (1983) was extracted and presented 
in Figure 3. 0.0-1. This figure illustrates the mission type, the anticipated 
launch schedule, maintenance time, mission planning, training and simulation 
time intervals. As can be seen, no mission overlaps exist which results in 
the operational elements being sized to support a single mission. 

It should be kept in mind that these data are only representative of what 
should be expected. In particular, planning and operations analyses should 
investigate the impact of variations in the relative frequency of the various 
classes, changes in the spacecraft characteristics, and other factors that 
may change and are a part of operational planning. 

3.1 REFERENCE MISSION DESCRIPTIONS 

The following paragraphs describe the types of reference missions evaluated 
during the study. To enable the identification of operational requirements 
from the many diverse missions, the individual missions were grouped into 
three major classes and analysis performed on each class. The three classes 
used were (1) Geosynchronous missions, (2) Sun Synchronous missions, and (3) 
Interplanetary missions. Characteristics of these mission classes are dis- 
cussed below. 

3.1.1 Geosynchronous Missions 

Several types of Geosynchronous missions are defined in the current traffic 
models. The IUS vehicle currently defined for this study has the capability 
to deploy spacecraft, but cannot retrieve spacecraft from any mission profile. 
Therefore, two distinct deployment classes of IUS missions exist for this 
study. They are, (1) expendable missions, where following spacecraft deploy- 
ment, the IUS vehicle is expended, and (2) reusable missions, where following 
Spacecraft deployment, the IUS vehicle returns to the Orbiter rendezvous 
box, and is retrieved by the Orbiter for return to earth. 

A typical Geosynchronous mission is shown in Figure 3. 1.1-1 for an IUS 
reusable (RIllS) deployment mission. As in the case of Space Tug missions, it 
was determined that missions could be represented by a standard set of building 
blocks where each block (or module) contained those operational functions (or 
tasks) required for mission completion. Once these buildings blocks were 
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defined, they could be interleaved to represent specific missions. Section 

3.2 describes this modular approach and contains the functions within each 
standard module. 

As an example. Figure 3. 1.1-2 illustrates the typical modules which would be 
used to represent an expendable IUS (EIUS) single placement Geosynchronous 
mission. 

3.1.2 Sun Synchronous Missions 

The Sun Synchronous mission class assumes an IUS deployment in low-earth 
orbit (^205 nm) by the Orbiter and a transfer to a spacecraft deployment 
target in a 900 nm circular orbit. After orbital trims, the IUS deploys the 
spacecraft, and, (1) in the expendable mission case, is terminated, or, (2) 
in the reusable mission case, executes a two burn sequence targeted to the 
Orbiter retrieval box. 

As in the Geosynchronous mission class, the standard operational modules 
were interleaved to represent the Sun Synchronous missions.. Figure 3. 1.2-1 
depicts a Sun- Synchronous mission for an expendable IUS mission. 
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01 


02 


03 


02 


03 



Figure 3. 1. 1-2. EiUS Mission Module Sequence for Geosynchronous Mission 



Figure 3. 1.2-1. EIUS Mission Module Sequence for Sun Synchronous Mission 


3.1.3 Interplanetary Missions 

The Interplanetary missions can be characterized as having high del'ta-veloci ty 
requirements and narrow launch windows. For the purpose of this study, only 
expendable IUS missions have been assessed. 
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The targeting requirements for using the IUS in a planetary mission are 
complex and will require a sophisticated prelaunch targeting program to 
optimize the IUS propellant loading when given a spacecraft description. The 
complexity of this mission makes it desirable to baseline a day to day launch 
on time. Prelaunch targeting shall determine the launch time and Orbiter 
orbital insertion targeting parameters (taken from the Space Shuttle data bank) 
necessary for IUS deployment and adjustment needs for IUS burns. The IUS 
onboard targeting for planetary missions is baselined, for this study, to be 
pre-loaded from the ground. 

As in the other mission classes, standard operational modules were interleaved 
to represent the interplanetary missions. Figure 3. 1.3-1 depicts an inter- 
planetary IUS mission for a single placement case.. 

3.2 MISSION MODULE TIMELINES 

3.2.1 Principles of Mission Modularization 

Prior Orbital payload placement studies have revealed that mission event 
sequences (timelines) can be modularized (subdivided into the longest consecutive 
sequence of events which occur in the same order for a particular function). 

The modularization of mission event sequences is a common technique used in 
most airborne flight programs to segregate similar computer functions. This 
technique simplifies maintenance of the program by limiting the effect of 
changes to smaller areas of consideration and facilitates the calling of 
routines when their particular application is required. 



Figure 3. 1.3-1. El US Mission Module Sequence for Interplanetary Mission 
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The development of the IUS mission modules (timelines) evolved from work on 
the NASA Tug studies, candidate IUS vehicle timelines, concurrent analysis, 
and past experience. The first step in the process was to identify the major 
functions common to any possible IUS. The major functions for IUS missions 
were found to be: 

• Launch Operations 

• On Orbit Coast 

• Main Engine Burn 

• Payload Placement 

• Kick Stage Separation 

• Orbiter Retrieval (Reusable IUS only) 

With these major functions it is possible to construct a sequence of functions 
which, satisfy the total IUS mission spectrum. 

After the identification of the major mission functions, the sub-functional 
sequence within each module was established. Flow charts are included with 
each mission module timeline to visually depict the major events within each 
module. The Orbiter, crew, IUS, and IUS Operations Center (IUS/OC) activities 
associated with each sub-function were constructed, sequenced, and timed. 

These activities are the events listed in each timeline. 

The identification of events have been accomplished by assigning a two digit 
number which represents the event position in the module sub-function sequence. 
This is the number immediately to the right in the identification number 
column of the timeline tables. The next two digits represent the general 
sequence of sub-functions within the module. Some sub-functions, like some 
events, however, are not necessarily sequential. The third double digit set 
of numbers are the module identification number. It is possible to extend 
the modules into a next numbering level which would then be the module 
groupings for a particular mission. The positive identification of events 
also permits the tracing and quantifying of events for analytical purposes. 

Duration times for sub-functions and associated events appear in seconds. 

These times are tabulated in columns opposite the identification number 
followed by a mission reference time which is related to a key event within 
the module. Key events are those events which commit the mission to a new 
phase. Bar charts to the extreme right have been created to provide a picture 
of event time duration and sequence relative to total module activity. Times 
for many events represent best estimates and are subject to change as re- 
finements in mission, vehicle and ground systems definition continue. 

3.2.2 IUS 'Launch 'Operations 

3. 2. 2.1 General 

The orbiter launch operations function begins in the prelaunch phase during 
the final integrated testing of the IUS and Spacecraft and culminates with 
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the IUS in low earth orbit activated and waiting for convergence of its 
targeting equations for its first main engine burn. Figure 3. 2. 2-1 is a flow 
chart illustrating the sequence of sub-functions during this period. Figure 
3. 2. 2-2 is a listing of the major IUS, Orbiter, and IUS control center, 
events (not allocated in timeline) occurring during a nominal Orbiter launch 
operation and IUS deployment phase. 

3. 2. 2. 2 Prelaunch Operations 

Prelaunch operations start at approximately T-2 hours prior to launch and 
continue until Orbiter lift off. During this time, the -terminal countdown 
is initiated and final activation and ground check out of IUS systems is 
accomplished. Components active or previously activated and checked out 
during this period are the computer (DMS), inertial measuring unit (IMU), and 
decoders and telemetry (RM IS) systems. The IUS will be placed in a safe con- 
figuration for the boost to orbit mode. 

3. 2. 2. 3 Ascent Operations 

During the boost to orbit by the shuttle, both the Orbiter crew and IUS/OC 
will monitor the safety critical IUS caution and warning parameters. Power 
to the IUS during this time period will be supplied by the Orbiter. The 
maintenance of a safe mode may require the venting of propellants which will 
be an automatic function accomplished by the IUS computer. 

3. 2. 2. 4 Deploy IUS 

The activation of the remaining IUS subsystems and verification for mission 
continuance 'will begin as quickly as possible after the Orbiter has achieved 
orbit. The Orbiter will initiate the deploy sequence by configuring the 
Orbiter bay and deployment equipment for deploy operations. The payload bay 
doors will be opened and the RMS will be mated to the IUS. 

Prior to the Orbiter circularization burn, the lUS/Orbiter state vector 
comparison and navigation and attitude update will be accomplished, if required. 
During this time the IUS is still secure in the Orbiter bay, a circularization 
maneuver by the Orbiter may be performed. After the burn, deployment will 
begin, the IUS electrical power will be transferred from the Orbiter 
to the IUS battery, and the IUS command and telemetry system will be activated 
and verified operational. With the IUS status data available via RF, all 
retaining latches will be released by the crew and the electrical umbilical 
and propellant dump lines disconnected. The IUS will then be raised from 
the Orbiter bay by the RMS to a position for release. With the concurrence 
of the IUS/OC, the Orbiter crew will release the IUS. 

3. 2. 2.5 Enable Attitude Hold 

The IUS will maintain a completely safe and non propulsive status .for 
approximately 90 seconds. This should be sufficient time for the Orbiter to' 
separate to a distance safe from any IUS attitude control system malfunction. 
After 90 seconds, a sequence will be initiated by either the IUS (or Orbiter 
command) which will activate the IUS attitude control system. The IUS will 
maintain a programmed attitude maneuver while the Orbiter retreats to a safe 
distance for main propulsion system activation. 
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Figure 3. 2.2-1. Standard iUS Launch Module Flow 
3. 2. 2. 6 Enable IUS Systems 

When the Orbiter has reached a safe distance of approximately 3000 feet 
(approximately 16 minutes), the IUS will begin its activation sequence for 
ACS and main propulsion system and enable continuance of the IUS mission. At 
this time the IUS will enter the on orbit coast mode and begin the countdown 
for first main engine burn. 

3.2.3 On Orbit Coast 


3. 2. 3.1 General 

The on orbit coast module provides the interim on orbit navigation guidance 
and control state between active mission modules. During these waiting 
periods, the overall mission plan can be reviewed and modified to accommodate 
real time mission variations. The duration of time spent in this module will 
be a function of the sequenced mission schedule maintained by the computer 
in the IUS flight program. The navigation update sequence and on orbit mission 
planning sequence are entered by ground command or as a result of special 
conditions and represent additional capability. Figure 3. 2. 3-1 is a flow 
diagram showing the module functional capability and the potential interface 
with other modules. Figure 3. 2. 3-2 is a listing of the major IUS and IUS/0C 
events common to this module. 

3. 2. 3. 2 On Orbit Guidance Navigation and Control 

The on orbit GN&C function provides for the maintenance of the IUS attitude 
and trajectory during the periods between mainstages, trimburns, payload 
placement, and Kick Stage separation. If a navigation update is required, 
the sequence can be commanded and accomplished during this time. 
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STANDARD 1US LAUNCH MODULE (01) 

The Orbiter launch operations nodule begins in the prelaunch phase during the final 
integrated teat during which there is ground operations control center involvement 
and terminates with XUS in the Space Shuttle orbit activated and awaiting convergence 
of its ta rgeting equations for its first main engine burn. 

EVENT EVENT 

EVENT DESCRIPTION EVENT NUMBER TImTiN TIMLIN 

uuitxiiurt MOOUL£ MISSI0N 

(SECS) (SECS) (HOURS) 


LAUNCH PREPARATIONS 

START SHUTTLE LAUNCH COUNTDOWN 
APPLY GROUND POWER 
START COUNTDOWN PREPARATIONS :PMSiLPS 
START SHUTTLE STANDBY STATUS 

PRELAUNCH OPERATIONS 

START COUNTDOWN 

ALIGN GUIDANCE COMPLETE 

START SAFETY MONITOR (CAUTION S WANR. 

LOAD GUIDANCE COMPUTER 

ALIGN IHU 

CALIBRATE SYSTEMS 

COMPARE IUS/ORB. PLATFORM & NAV, DATA 
START COMPUTER SELF TEST ROUTINE 
START PMS LIMIT CHECKS (DMS) 

VERIFY DISCRETE STATUS (DMS) 

VERIFY RESPONSE TO UPLINK COMMANDS 
VERIFY RF PERFORMANCE (QUALITATIVE) 
MONITOR BATTERY 

VERIFY TANK PRESSURES (PROPULSION) 
VERIFY VALVE POSITIONS (PROPULSION) 
VERIFY SPACECRAFT STATUS 
UPDATE NAVIGATION DATA 
START SAFETY MONITORING (CSW) 

TRANSFER TO ORBIT POWER 

INITIATE GUIDANCE TO INERTIAL NAV, 

ASCENT OPERATIONS 

MONITOR CAUTION & WARNING 

PERFORM LIFTOFF 

INJECT IN TRANSFER ORBIT 


T-18 Hours 


On Orbit Coast 


01.01.00 

57600 

01.01.01 


01.01.02 


01.01.03 


01.01.04 


01.02.00 

7200 

01.02.01 

5400 

01.02.02 

200 

01.02.03 

1800 

01.02.04 

200 

01.02.05 

200 

01.02.06 

200 

0i.02.07 

200 

01.02.08 

200 

01.02.09 

200 

01.02.10 

200 

01.02.11 

200 

01.02.12 

200 

01.02.13 

1200 

01.02.14 

200 

01.02.15 

200 

01.02.16 

200 

01.02.17 

200 

01.02.18 

800 

01.02.19 

10 

01.02.20 

3 

01.03.00 

531 

01,03.01 

531 

01.03.02 


01.03.03 

150 


10 HOU) 
w o 8 S 


Event tine in hundreds of seconds 
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Figure 3.2.2-2. Standard /US Launch Module Timeline 
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STANDARD IUS LAUNCH MODULE (01) (CONTINUED) 


EVENT NUWER 


01.04.00 


VERIFY PAYLOAD BAY DOORS OPES 01.04.01 
DEPLOY RMS 01:04.02 
GRAPPLE PAYLOAD (CCTV) 01.04.03 
CONFIGURE ORBITER FOR RF COMM. 01.04.04 
TRANSFER TO IUS POWER 01.04.05 
RJ TELEMETRY 6 COMMA.'® VERIFICATION 01.04.06 
(ACTIVATE UPLINK ARMING BIS) 

VERIFY IGS BITE STATUS 01.04.07 
IUS/ORBITER STATE VECTOR COMPARE 01.04.08 
UPDATE IUS NAVIGATION AND ATTITUDE 01.04.09 
ORBITER CIRCULARIZATION MANEUVER 01 04.10 
DISABLE CRADLE DUMP VALVE STATUS 01.04.11 
MONITOR FUNCTIONS 

OPEN CRADLE DUMP VALVES 01.04.12 
DISABLE DEDICATED 4 BACKUP C&N 01.04.13 
RELEASE IUS LATCHES 01.04.14 
DISCONNECT ELECTRICAL UMBILICAL 01.04.15 
DISABLE DUMP LINE DISCONNECT 01.04.16 
STATUS MONITORS 

DISCONNECT PROPELLANT DUMP LISES 01.04.17 
EXTEND PAYLOAD OS RMS (CCTV) 01.04.17 
IUS /RMS SEPARATION 01.04,19 


EVENT DESCRIPTION 


DEPLOY IUS 


ENABLE ATTITUDE HOLD 


01.05.00 


SEPARATE USING ORBITER RCS (240 ft ? €1.05.01 

3 fps -V) 

DISABLE TPS/IGPS AND ACS ARMING BUS Cl. 05. 02 

VOLTAGE STATUS MONITOR FUNCTIONS 
ENABLE TPS 6 IGPS BUSES 01.05.03 

OPEN ACS PYRO VALVE AND ENABLE ACS 01.05.04 

ARMING BUS 

ACTIVATE ACS AND GUIDANCE ATTITUDE 01.05.05 

HOLD SOFTWARE 

IUS IM DATA MONITOR 01.05.06 




Figure 322-2. Standard IUS Launch Module Timeline (Continued) 











ENTRY 


EXIT 



Figure 3. 2. 3-1. Standard I US On-Orbit Coast Module Flow 


3. 2. 3. 3 On Orbit Mission Planning 

The nominal mission will not require any adjustment in the preplanned 
sequence of events. However, should major perturbations occur, such as missed 
first mainstage opportunity, early engine cutoff, or anything negating the 
nominal sequence, then the capability exists through this function to change, 
by reloading the IUS computer, the mission sequence in a manner best suited 
to the current realtime conditions. 

3. 2. 3. 4 Trim Burn Maneuver 

The capability will exist, within the on orbit coast mode, to institute, by 
ground command, minor trajectory corrections using the attitude control 
system. This can be done by commanding a vehicle attitude and ACS thrust for 
a specific duration of time. 

3.2.4 Mainstage 
3. 2. 4.1 General 

The mainstage module is utilized each time the IUS must make a major maneuver 
such as a phasing burn, transfer orbit burn, large midcourse correction, and/or 
circularization. This module is entered with the IUS in the on orbit coast 


3-17 



















mode after accomplishing the desired major thrusting maneuver. Nominal time 
in the module as currently defined is approximately five minutes for preburn 
preparations, and three minutes for closing out burn operations. Figure 
3. 2.4-1 depicts by flow chart the major function sequence within the module. 
Figure 3.2.4. -2 lists the major IUS and IUS/OC events and their respective 
times. 

3. 2.4. 2 Main Engine Burn Preparation 

This sequence occurs immediately prior to the main engine burn. The IUS 
is oriented by the ACS to the proper attitude for burn initialization. The 
main propulsive system is configured for engine ignition. 

3. 2.4.3 Perform Engine Burn 

Immediately prior to engine ignition, the burn sequence is entered and the 
mainstage GN&C is initiated. If scheduled mainstage ignition should fail to 
occur, the flight program will terminate the burn sequence and revert to the 
on orbit coast mode. In the case of the first mainstage burn, a second 
opportunity sequence will be resident in the flight program and will, be auto- 
matically implemented. 

Prior to mainstage ignition, the IUS/OC will initiate burn tracking if 
available and will also monitor and verify the onboard events as they occur. 
During the active mainstage burn, the IUS/OC will monitor the vehicle events 
and trajectory and provide backup engine cutoff by command. The Orbiter crew 
will also be in a standby mode for the first mainstage engine burn. 

3. 2. 4. 4 Terminate Burn 

The main engine cutoff will be calculated and issued by the flight program 
and the terminal burn parameters telemetered. The IUS/OC will provide backup 
engine cutoff capability and will terminate burn tracking and evaluate the 
burn end conditions to determine if burn objectives have been met. The flight 
program will automatically exit to the on orbit coast mode where mission 
plans can be modified and an ACS trim burn performed if needed. 

3.2.5 Payload Placement 

3. 2. 5.1 General 

The payload placement function incorporates those activities required to enable 
and deploy the IUS payload. Unlike the Tug, the expendable IUS will not engage 
in placement payload checkout since there is no means to return to the Orbiter. 
After deployment of the payload, the IUS will re-enter the on 1 orbit coast mode 
where another mainstage burn could be programmed or commanded to place the 
expended IUS in another oribt which will not impact spacecraft operations. 
Figure 3. 2. 5-1 is a flow chart showing the enable and release sequence and the 
on orbit coast entry and exit interface. Figure 3. 2. 5-2 is a listing of the 
major events and respective event times within the module. 
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ENTRY 


EXIT 



Figure 3.2.4-1. Standard fUS Main Engine Bum Module Flow 


3. 2. 5. 2 Placement Preparation 

Placement preparation of a Spacecraft will include activating electrical 
power and any other activation sequencing which can be handled by IUS 
commands. 

3. 2. 5. 3 Release Payload 

The process for releasing a spacecraft will include the arming and firing . 
of the release mechanism. The IUS ACS will be temporarily disabled for about 
two minutes to allow the spacecraft and IUS to drift apart. The IUS ACS will 
then be automatically activated and the IUS will enter the on orbit coast 
mode. 

3.2.6 Kick Stage Separation 

3. 2. 6.1 General 

The Kick Stage separation module describes the activities required to 
enable and deploy a kick stage. After placement, the IUS enters the on orbit 
coast mode. Figure 3. 2. 6-1 is a flow diagram illustrating the separation 
and separation sequence. Figure 3. 2. 6-2 lists the major events and event 
times associated with this operational function. Like all expendable IUS 
payloads, predeployment checkout is. not necessary since the mission is 
irreversable at this point in time. 

3. 2. 6. 2 Kick Stage Separation Preparation 

Separation readiness for a Kick Stage will involve activation of the 
Kick Stage telemetry and an attitude reference update. The IUS will perform 
any transfer and alignment maneuvers necessary to position the Kick Stage 
prior to placement. The final preparation steps will involve arming and 
activations ordinance and. transferring the kick stage to its own internal 
electrical power. 

3. 2. 6. 3 Kick Stage Separation 

The process for releasing a Kick Stage will include the arming and firing 
of the separation ordinance. The IUS will perform a separation ACS maneuver 
and enter the on orbit coast mode. 
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STANDARD IUS MAIN ENGINE BURN MODULE (03) 

The mainstage module is utilized each time Che IUS must make a major maneuver such as 
a phasing burn, transfer orbit burn, large mid-course correction, circularization, etc. 
This module is entered with the IUS in the on-orbit coast mode and exits in the on- 
orbit coast mode after the accomplishment of the desired major thrusting maneuver. 


ENTRY: On Orbit Coast 


EXIT: On Orbit Coast 


EVENT DESCRIPTION 


MAIN ENGINE BURN PREPARATION 

OPEN PROPELLANT LINE CAVITY 
VENTS (PLCV) (1ST BURN ONLY) 
PROPELLANT SETTLING - ON 
CLOSE PLCV & OPEN PREVALVES 
PROPELLANT SETTLING - OFF AND 
OPEN PREVALVES TO POSITION 2 
(FULL-OPEN 1ST BURN ONLY) 

ORIENT FOR 1ST BURN 
ORIENTATION COMPLETE 
PROPELLANT SETTLING - ON 
PRESSURIZE PROPELLANT TANKS 
(2 VALVES) 

STAR! HYDRAULICS PUMP AND 
PRESSURIZE PROPELLANT TANKS 
(4 VALVES) 

PERFORM ENGINE BURN 

START MAIN ENGINES 
INITIALIZE DFCS 
PROPELLANT SETTLING - OFF 
NO IGNITION (REVERT TO ON ORBIT 
NAVIGATION AND SELECT 2ND 
OPPORTUNITY MISSION PLAN) 

MONITOR EVENT SEQUENCE 

GROUND BACKUP ENGINE CUTOFF COMMAND 

INITIATE AND PERFORM BURN TRACKING 

TERMINATE ENGINE BURN 

DISABLE COMMAND SHUTDOWN 
SHUTDOWN MAIN ENGINE 
SHUTDOWN HYDRAULICS 
DISABLE PRESSURIZATION (2 VALVES) 
DISABLE PRESSURIZATION (4 VALVES) 
TELEMETRY BURN DATA 
EXIT SEQUENCE TO ON ORBIT NAVIGATION 
MONITOR CUTOFF AND PROVIDE GROUND 
BACKUP ENGINE CUTOFF COMMAND 
COMPARE CALCULATED AND ACTUAL BURN 
DATA 

INITIATE COAST TRACKING 
EXIT TO ON ORBIT COAST 


EVENT NUM8ER 


EVENT 

mmm \ ™ule H 


Event time in tens of seconds 


03.01.01 

03.01.02 

03.01.03 


03.01.04 

03.01.05 

03.01.06 

03.01.07 


03.02.01 

03.02.02 

03.02.03 


03.02.04 

03.02.05 

03.02.06 

03.02.07 


03.03.01 

03.03.02 


03.03.04 

03.03.05 


03.03.07 

03.03.08 

03.03.09 


TIME IN 
MISSION I 

(HOURS) | a a 8 a g 
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Figure 3.2A-2. Standard IUS Main Engine Bum Module Timeline 







ENTRY 


EXIT 



Figure 3. 2:5-1. Standard I US Payload Placement Module Flow 


3.2.7 Orbiter Retrieval' 

3. 2. 7.1 General 

The retrieval of the IUS from orbit by the Orbiter is accomplished after the 
IUS final main engine burn which places the IUS in a low earth orbit. 
Retrieval by the Orbiter is applicable only to the reusable IUS. The pro- 
cedure for retrieval is essentially the reverse of the deployment sequence 
with the- IUS systems being deactivated and safed rather than activated. 
Figure 3. 2. 7-1 illustrates the 'flow of major functions for the retrieval of : 
the IUS from orbit. Figure 3. 2. 7 -2 lists the events associated with this 
activity. 


3. 2. 7. 2 Deactivate IUS Main Propulsion 

Prior to deactivation of the IUS main propulsion system, the IUS/OC and Orbiter 
crew will concur that the IUS will not be required to make a propulsive maneuver 
to assist in orbiter retrieval. After this decision, the IUS propulsive system 
will be safed by dumping both oxidizer and fuel. Upon completion of propellant 
safing, the IUS will assume the retrieval attitude and rendezvous aids will be 
activated. The IUS/OC will notify the Orbiter crew that the IUS is ready for 
retrieval. 

3.2.7. 3 Maneuver Orbiter For Intercept 

The orbital intercept maneuver will be the responsibility of the Orbiter crew. 

The IUS, in a safe condition and in a prescribed attitude with rendezvous aids 
active, will wait in a fixed low earth orbit. The IUS/OC will continually monitor 
the IUS status and keep the Orbiter crew posted. 

3. 2.7.4 .Orbiter Acquire- IUS Telemetry 

When the Orbiter closes- within range IUS telemetry will be acquired and command 
capability of IUS By' the crew established. 

3. 2. 7. 5 Maneuver Orbiter For Rendezvous 

The terminal 'rendezvous maneuver will be the responsibility of the Orbiter 
Crew, the IUS will maintain a safe attitude and configuration during this time. 
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STANDARD IUS PAYLOAD PLACEMENT MODULE (04) 

The payload placement module lists the activities required to enable and deploy 
a payload. The IUS is returned to an on orbit coast node after payload placement. 


EVENT DESCRIPTION 


EVENT NUMBER 


EVENT 

DURATION 


EVENT 
START 
TIME IN 
MODULE 


(SEC) 


(SEC) 


EVENT 
START 
TIME IN 
MISSION 
(HOURS) 


PLACEMENT PREPARATION 


04.01.00 


190 I 0 


INITIALIZE PAYLOAD SYSTEMS 
ENABLE COMMAND ACCEPT 


04.01.01 

04.01.02 


180 

10 


0 

180 


RELEASE PAYLOAD 


04.02.00 


132 


190 


ARM SPACECRAFT SEPARATION 
FIRE SPACECRAFT SEPARATION 
DISABLE ACS 
ENABLE ACS 

EXIT TO ON ORBIT NAVIGATION 


04.02.01 

04.02.02 

04.02.03 

04.02.04 
04.02.04 


1 

4 

125 

1 

1 


190 

191 
195 

320 

321 


ENTRY! On Orbit Coast 
EXIT: On Orbit Coast 


Event time in tens of seconds 
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Figure 3.2.5-2. Standard IUS Payload Placement Module Timeline 


ENTRY 


EXIT 



Figure 12.6-1. Standard !US Kick Stage Separation Module Flow 


The IUS/OC will continually monitor IUS status and keep the Orbiter crew posted. 

At the request of the Orbiter crew and with IUS/OC concurrance, command control 
of the Tug will be transferred from -the IUS/OC to the Orbiter crew. 

3. 2. 7. 6 Prepare For Retrieval 

The Orbiter will have the option of either flying around , or commanding an attitude 
change rate to visually inspect the IUS and payload if desired. The Orbiter 
will be configured by the crew for retrieval operations. Included in these 
operations are opening- the payload bay doors, assuming the retrieval alignment 
attitude and activating the RMS and IUS cradle latches. The Orbiter crew will 
get final concurrence from the IUS/OC that the IUS is ready for retrieval. 

3. 2.7. 7 • IUS Retrieval 

IUS retrieval begins with the extention of the. RMS and the disabling of the IUS 
attitude control system. When RMS/-IUS mate is accomplished, the ACS will be 
activated. Checks will be made at this time to verify the IUS is safe for re- 
traction into the bay. The Orbiter crew will then retract the IUS into the IUS 
cradle and secure the latches. The RMS wi-11 be disconnected and stored and the 
IUS/Orbiter umbilicals connected. When hardwire caution and warning data is 
established IUS RF will be terminated. IUS power will be transfered to the 
Orbiter and the IUS and Orbiter will be configured for deorbit operations. 

3. 2. '7. 8 Deorbit 

The deorbit sequence will be accomplished by the Orbiter and crew with the IUS 
in a passive configuration. The only IUS activity during this period will be 
the maintenance of the IUS safe condition and the caution and warning data system. 
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STANDARD IUS KICK STAGE SEPARATION MODULE (05) 

The kick stage placenent codole defines the activities required to activate and 
deploy a kick stage. After deployment the IUS enters the on orbit coast node 


ENTRY: On Orbit Coast 


EXIT: On Orbit Coast 


EVENT DESCRIPTION 


KICK STAGE SEPARATION PRE?ARATIQN 

ACTIVATE KICK STAGE TELEMETR) AND 
INITIATE ATTITUDE UPDATE 
PERFORM TRANSFER ALIGN AND MANEUVER 
TO RELEASE ATTITUDE 
TRANSFER SC AND KICK STAG- TO 
INTERNAL POWER AND ENABLE ACS 
START VALVE 
ENABLE SEPARATION 

KICK STAGE SEPARATION 

INITIALIZE KICK STAGE, UNCAGE 
GYROS AND FIRE ACS START VALVE 
FIRE KICK STAGE SEPARATION 
ORDNANCE 

ENABLE ACS PULSING 
EXIT TO ON ORBIT COAST 


event event 

EVENT START START 

DURATION ^ TIME IN 

DURATION HQDULg HISSI0N 

(SEC) (SEC) (HOURS) 


Event tine in tens of seconds 



Figure 32.6-2. Standard IUS Kick Stage Separation Module Timeline 



Figure 32.7-1. Standard Orbiter Retrieval Module for Reusable IUS 


ORIGINAL PAGE IS 
OE POOR QUALITY 































3-20 


STANDARD 0RB1TER RETRIEVAL NODULE (06) 

Retrieval Operation begins after the IUS final rendezvous main engine 
burn and terminates with the return of the Orbiter to earth. This 
module is applicable for Reusable IUS only. 


ENTPY. On-Orbit Coast 

EXIT. Post Landing Ground Cortrol 



EVENT DESCRIPTION 

EVENT NUMBER 

EVENT 

DURATION 

(SEC) 


DEACTIVATE IUS MAIN PROPULSION 

01.00 

2230 

-2230 

VERIFY TUG PROPULSION SYSTEM NOT 



-2230 

NEEDED FOR TUG/ORBITER RENDEZVOUS 

01.01 

300 

COMMAND TUG RETRIEVAL SAFING 

01.02 

10 

-1930 

ACS PROPELLANT SETTLING 

01.03 

10 

-1920 

DUMP OXIDIZER AND FUEL 

01.04 

1500 

-1910 

OPTIMIZE PRESSURES 

01.05 

100 

- 410 

DISABLE MAIN PROPULSION ELEC. POWEI 

01.06 

10 

- 310 

MONITOR AND VERIFY IUS SAFE 


100 


COMMAND RETRIEVAL ATTITUDE 


50 


VERIFY ATTITUDE AND ATTITUDE HOLD 


50 

- 150 

ACTIVATE TUG RENDEZVOUS AIDS 


50 

- 100 

VERIFY TUG READY FOR RETRIEVAL 


50 

- 50 

MANEUVER ORBITER FOR INTERCEPT 

02.00 

1300 

ORBITEP 

FUNCTIOt 

DETERMINE RANGE AND RANGE RATE 

02.01 

250 

DETERMINE INTERCEPT MANEUVERS 


100 


COMPUTE TPI BURN PARAMETERS 

02.03 

200 


MANEUVER TO TPI BURN ATTITUDE 

02.04 

500 


PERFORM TPI BURN (OMS ENGINES) 

02.05 

50 


PERFORM COURSE CORRECTION OPS. 

. . . .02.06 

200 


ORBITER ACQUIRE IUS Til 

03.00 

600 


ON-ORBIT NAVIGATION MODE 
1US/0RBITER RF TM AND COMMAND LINK 

.... 03.01 

600 


ESTABLISHED 

.... 03.02 

600 


MANEUVER ORBITER FOR RENDEZVOUS 

. . . . 04.00 

1150 


DETERMINE RANGE AND RANGE RATE 

04.10 

250 


COMPUTE TPF BURN PARAMETERS 

04.02 

200 


ORIENT ORBITER FOR TPF BURN 

04.03 

200 


VERIFY ORBITER REAOINESS FOR BURNS 

04.04 

200 


PERFORM TPF BURNS (OMS/APS) 

04.05 

200 


VERIFY TUG SAFE FOR DOCK 

04.06 

200 



EVENT 
START 
TIME IN 
MISSION 
(HOURS) 


Figure 3. 2. 7-2. Standard Orbiter Retrieval Module Timeline 
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STANDARD ORBITER RETRIEVAL MODULE (06) (Continued) 


EVENT DESCRIPTION 

EVENT HUMBER 

EVENT 

DURATION 

(SEC) 

EVENT 
START 
TIKE IN 
MODULE 
(SEC) 

PREPARE FOR RETRIEVAL 

05.00 

1000 

-1350 

IUS ATTITUDE HOLD MODE 

05.01 


-1350 

ORBITER INSPECTION OF TUG 



-1350 

ORB I TER/ 1 US RETRIEVAL ALIGNMENT 



-1100 

. (ORBITER) 




PAYLOAD BAY DOORS OPEN 



- 850 

ORBITER CONFIGURED FOR RETRIEVAL 



- 350 

IUS RETRIEVAL 


1110 

- 100 

RMS EXTENDED 

06.01 

100 

- 100 

DISABLE IUS ACS 

06.02 

100 

- 100 

RMS/ 1 US MATE 

06.03 

50 

PFF 

DEACTIVATE IUS ACS 

06.04 

10 

50 

VERIFY IUS SAFE TOR RETRACTION 

. . . . 06.05 

100 

£0 

MOVE IUS INTO BAY/ CRADLE 

06.06 

300 

160 

LATCH IUS T(3 CRADLE 

06.07 

60 


RECONNECT UMBILICALS 

06.08 

60 

■I 

VERIFY CAUTION AND WARNING MONITOR 

06.09 

10 

580 

IDS RF OFF 

06.10 

10 

590 

IUS POWER TPANSFEP. 

06.11 

10 

600 

CONFIGURE IUS FOR RE-ENTRY 

06 12 

100 

610 

CONFIGURE ORBITER BAY FOR RE-ENTRY 

06.13 

300 

710 

DEORBIT 

07.00 

ORBITER 




FUNCTIONS 


PERFORM DEORBIT COAST OPERATIONS 

07.01 



PERFORM DEORBIT MANEUVERS 

. . . . 07.02 



PERFORM ENTRY AND DESCENT MANEUVERS 

.... 07.03 



PERFORM APPROACH AND LANDING 

07.04 




EVENT 
START 
TIME IN 
MISSION 
(HOURS) 


Reference Ti me 


Event Time in hundreds of seconds 



i — i — 1 — 1 — I--I — 1| 

f44444-» 
f44444-l| 
•r4444-r-<! 

I I » I I • * 

r*ffr*r* 


Figure 3.2J-2. Standard Orbiter Retrieval Module Timeline (Continued) 













INTERIM UPPER STAGE CONFIGURATION DESCRIPTION 

A baseline IUS configuration was established to provide a basis for the 
operational and costing analyses required in the study effort. Both 
expendable and reusable configurations were used during the initial study 
phases, however, the latter part of the study concentrated on the expendable 
IUS. This section gives an overview of the expendable IUS with deltas 
shown- for the reusable IUS. Unless otherwise specified, IUS discussions 
assume the same configuration for both EIUS and RIUS. The baseline EIUS 
and RIUS are derived from information provided by NASA in references 3 
through 5. 

4.1 OVERALL IUS DESCRIPTION 

A modified existing vehicle is baselined for the Orbital Operations Study. 

The Expendable IUS (EIUS) is ten feet in diameter and approximately 14.3 
feet in length. It has a liftoff weight of approximately 27,300 lbs. and a 
dry stage weight of about 3600 lbs. The EIUS consists of a control module 
and a propulsion module. The propulsion module houses the liquid propellant 
tanks, pressurization system and two AJ-10-138 hydraulically-gimballed engines. 
The Control Module houses the EIUS avionics, and the monopropellant hydrazine 
Attitude Control System (ACS). The control module can be separated from the 
propulsion module and remain with the spacecraft to provide attitude control 
and velocity increments as required. A deployment adapter (or cradle) will 
be designed for ElUS/Orbiter interface and to support the EIUS and spacecraft 
while in the Orbiter bay and during deployment. 

The Reusable It'S (RIUS) is a modified EIUS with added provisions for Or.bi.ter 
retrieval. The Reusable stage is 10 feet in diameter and 19.2 feet long with 
a dry weight of 4400 lbs. and a liftoff weight of approximately 36,800 lbs. 

The propellant tanks lengths are measured to accomodate the additional fuel 
requirements, and minor additions or revisions are made to components to allow 
for longer mission durations and recovery operations. 

4.2 PROPULSION SUBSYSTEM 

The following is a summary of the IUS propulsion subsystem and its pertinent 
operational characteristics as baselined for the IUS missions. 

4.2.1 Main Engine 

The IUS engine is the multiple restart, pressure fed, liquid bipropellant 
engine utilizing storage propellants. The engine start sequence is initialed 
by applying a 28 vdc signal to a pilot valve to a cavity behind the bi- 
propellant valve power position. Opening time is controlled by an orifice 
located between the pilot valve and bi propel! ant valve. Propellants from the 
bipropellant valve flow into the fuel and oxidizer manifolds of the injector 
and are injected into the thrust chamber where hypergolic ignition occurs. 
Propellant flowrates to maintain the design mixture ratio for the engine 
system are controlled by balanced orifices located at the bi propel! ant valve 
inlets. Termination of the 28 vdc signal to the pilot valve allows the 
bi propel! ant valve cavity to be vented through the pilot valve overboard vent 
tube. The bipropellant valve spring then forces the fuel poppet and oxidizer 
stem assembly to the closed position terminating fuel and oxidizer flow. 
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4.2.2 Pressurization 


The EIUS pressurization subsystem utilizes helium gas stored in spherical tanks 
for propellant tank pressurization. The helium gas is regulated by two control 
valve assemblies with filters and redundant solenoid operated shutoff valves 
controlled by redundant and propellant tank pressure sensing switch assembly. 
Check valves in each propellant tank pressurization inlet line prevent vapor 
backflow and possible vapor mixing during nonflow periods. If propellant 
vapors leak past the check valves, they are vented overboard through the 
bleed orifice. 

Onboard redundancy is avilable to assure mission success. If any solenoid 
valve malfunctions, the flow is still controlled by the remaining valves. 

For example, if a valve fails open, the series arrangements provides a second 
valve to shut off the flow. If a valve fails closed, the parallel arrange- 
ment provides a second flow path. Burst disks are provided on each pressur- 
ization leg to provide burst/ relief portection. 

The pressurization system also includes a propellant utilization system which 
provides increased vehicle performance by reducing mixture ratio dispersions. 
Oxidizer and fuel pressurant relief valves prevent tank over pressurization. 

4.2.3 Propellant Management . 

The propellant management subsystem stores, and, when required, distributes 
the fuel and oxidizer to the main engines. It consists of fuel and oxidizer 
tanks, propellant tank trap and screen assemblies, propellant utilization 
sensors, feedlines for propellant fill, drain and dump, and vent and pressur- 
ization ■ 1 ines. 

The PU system utilizes discrete level sensors located in each propellant tank 
to sense propellant levels and control propellant utilization. The control 
system uses pressurant gas to control the flow rates (mixture ratio). The 
control unit is activated by three switches which increase, decrease, or maintain 
ullage pressure. The switch selection is determined by the computer based on 
level sensor error signals. 

The propellant isolation is accomplished by motor operated prevalves installed 
in the feedlines to provide double propellant isolation to prevent accidental 
engine operation. Dump valves are in the dumpline downstream for the 
prevalves. For abort dumps, the prevalve and dump valves are commanded open 
and the propellant dumped through the Orbiter overboard dump system. Pressure 
switches will close valves and deactivate the pressurization system when the 
dump is accomplished. 

In case of mission abort after IUS deployment, the dump valves will be open, 
the pressurization system activated, and the propellant dumped. After dumping, 
the engine feedlines will be purged, the valves closed and the tanks repressur- 
ized. 
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4.2.4 Attitude Control System (ACS) 

The IDS ACS is a blowdown, storable hydrazine liquid monopropellant, variable 
pulse width system which provides attitude and vernier velocity maneuvers. 

The ACS uses a hydrazine liquid monopropellant and a gaseous nitrogen pressu- 
rant. Six rocket engine modules consists of two rocket engine assemblies 
each. The engine arrangement provides engine-out redundancy in all three 
control axes. 

4.2.5 Hydraul i cs 

The IUS hydraulics system consists of a sealed electric motor-driven pump/ 
reservoir hydraulic lines, fittings, and four electrohydraulic mechanical 
feedback activators. IUS thrust vector control is accomplished by gimballing 
the two main engine assemblies. The activator position is sensed by a spring 
loaded cam follower and mechanically summed with the computer input common on the 
Servovalve torque motor/flapper assembly. 

4.3 AVIONICS SUBSYSTEM 

The IUS avionics is a centralized avionics system which consists of the 
following subsystems: 

• Guidance, Navigation and Control 

• Electrical Power 

• . Data Management and Instrumentation 

• Communications 

The following sections give an avionics overview and a brief summary of the 
subsystems and their flight operations related characteristics. 

4.3.1 Avionics Overview 

The Expendable IUS avionics configuration is shown in Figure 4. 3. 1-1 and the 
Reusable IUS avionics configuration is shown in Figure 4. 3. 1-2. The major 
differences between the' two configurations are the additions of an extra 
165 amp-hr battery, of computer storage, and of a star tracker for attitude 
updates for the Reusable IUS. 

The baseline EIUS used as a basis for the IBM analyses and costing is an 
existing vehicle modified to accomplish the basic EIUS mission. The EIUS 
avionics are basically simplex and designed for a short duration mission. 

A digital computer with 16K of 24 bit storage provides the onboard computation 
capability. The IMU provides an inertial reference system and the computer 
provides the control signals for the hydraulics and the sequencing of the 
ACS engines and electrical systems. Two batteries provide the onboard power 
requirements. Telemetry is collected by the remote multiplex units (RMU) 
and formatted by the RMIS. The communications provide tracking, telemetry 
and command interface with the ground and Orbiter. 

The interface adapter contains the provisions for making the IUS external 
interfaces compatible with the Orbiter and GSE. The EIUS command decoders 
also contain additional provisions for computer inputs, Spacecraft commands 
and IUS sequencing. Spacecraft telemetry could be integrated with IUS .telemetry 
by inputs to the IUS RMU's. 
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Table 4. 3. 1-1 gives a summary of the major IUS subsystems components, a 
redundancy summary, backup components and functions of the components. An 
asterisk indicates critical IUS components. As shown, little redundancy 
exists for the IUS avionics components, no backup capability is available and 
most components are mission critical. 

4.3.2 Guidance, Navigation and Control 

The IUS GN&C subsystem shown in Figure 4. 3. 2-1 consists of an inertial platform 
which senses vehicle movement, a computer which solves the GN&C' equations and 
provides onboard sequencing and malfunction detection support, and hydraulic 
activators and attitude control thrusters that control vehicle orientations 
and maneuvers. 

The inertial platform is an I MU which provides delta velocity and delta 
attitude information to the computer for guidance and navigation processing. 

The I MU is a four-gimbal all attitude platform stabilized with three single- 
degree-of-freedom rate integrating gyros and the accelerometers to sense 
accelerations. 

The digital computer is the heart of the IUS avionics. It performs the 
navigation and guidance processing and generates control commands as well 


Table 4.3.1 -1. EIUS Operational Redundancy Summary 


COMPONENT/SUBSYSTEM 

REDUNDANCY 

BACKUP 

FUNCTION 

* IMU 

SIMPLEX 
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INERTIAL ATTITUDE 
REFERENCE 

* COMPUTER 

SIMPLEX 

- 

ONBOARD CONTROL AND 
PROCESSING 

RMIS (TELEMETRY) 
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TELEMETRY DATA ■ 
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POWER GENERATION 
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ORBITER, GROUND 
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PROPULSION SYSTEM 
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REDUNDANT 
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ATTITUDE CONTROL, 
LOAD LEVEL THRUST 

* MAIN PROPULSION 
SYSTEM 

_ . 

SOME REDUNDANCY 


HIGH ENERGY THRUST 


* SYSTEMS MANDATORY FOR EIUS OPERATION 
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Figure 4.3.2-1. IUS GN&C Subsystem Block Diagram 




as performing event sequencing and some malfunction detection. The computer 
I/O interfaces with six IMU velocity and attitude inputs, four hydraulic 
activator outputs, and 12 ACS nozzle outputs. Digital flight control 
equations are used for GN&C processing. Built-in malfunction detection logic 
performs sum checks and reasonability tests to detect and correct for computer 
transients. 

The computer interfaces with the electrical sequencing system and can issue 
up to 34 ground! eg switching discrete outputs for sequencing of IUS loads, 
valves or switches. It also accepts discretes from the PU System and controls 
the switch setting for the helium tank pressurization system. The computer 
telemetry is routed to the RMIS for insertion into the IUS telemetry stream, 

A star tracker interfaces with the computer for altitude update for the 
Reusable IUS only. The star tracker takes two readings at different RIUS 
orientations for update computations which are performed by the computer. 

The angle data from the star tracker is input to the computer. 

The EIUS require 16K of 24 bit words and the RIUS 24K of 24 bits words for 
onboard software storage. As stated, the EIUS performs the basic GN&C 
computations and sequencing, while additional software is required by. the 
RIUS for star tracker computations and the return and retrieval operations 
software required for a Reusable vehicle. 

4.3.3 Data Management and Instrumentation 

The IUS data management and instrumentation subsystem consists of a data 
bus Remote Multiplexed Instrumentation System (RMIS) with remote terminals, 
measurement translators, signal conditioning, and a 10 vdc power supply. 

A schematic of the subsystem is shown in Figure 4. 3. 3-1. The RMIS converter 
interrogates six RMU's in a programmed sequence and integrates their response 
into a 16 or 64 KBPS PCM format along with the bi levels, computer data, and 
sync pulses. The RMIS is synchronized by the computer to allow insertion of 
the computer data into the PCM format. 

An IUS (both EIUS and RIUS) measurement list summary is given in Table 
4. 3. 3-1 and an uplink command list is given in Table 4. 3. 3-2. 

4.3.4 Communications 

The IUS communications, shown in Figure 4. 3.4-1, includes the antennas, 
transmitter, receivers, and decoders for external' RF interface. The components 
are dual redundant except that only one transmitter is baselined for the 
Expendable IUS. The subsystem includes the capability for telemetry, tracking 
and command interface and is compatible with the Orbiiter and STDN as shown in 
Figure 4. 3.4-2. It provides a 16 or 64 Kbps downlink interface with the 
ground and a 16 Kbps telemetry link with the Orbiter. It accepts the 2 Kbps 
command link from both the Orbiter and ground.. 
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Figure 4.3.3-1. IUS Data Management and Instrumentation Block Diagram 




Table 4.3.3-1. I US Measurement List Summary 


MEASUREMENT 

DISCRETE 

• ANALOG 

IMU 

— 

21 

COMPUTER 

2 

12 

FLIGHT CONTROL 

12 

3 

HYDRAULICS 

— 

5 

COMMUNICATIONS 

21 

20 

ELECTRICAL 

23 

18 

INSTRUMENTATION 

— 

6 

ENGINES 

— 

26 

PRESSURIZATION/PROPELLANT 

12 

11 

PROPELLANT UTILIZATION 

— 

6 

STRUCTURAL/THERMAL 

— 

6 

CRADLE 

5 

2 


75 

136 


The command decoder provides the command, interface with the Orbiter while 
attached. The decoders accept commands and distribute them to the computer, 
IUS electrical sequencing system, and Spacecraft. 

Five antennas are included on the IUS. Three are located 120 degrees apart 
on the circumference of the vehicle, while two are located pointing towards 
the front and rear of the vehicle to assure complete spherical coverage. 

4.3.5 Electrical Power 

The IUS electrical power subsystem consists of a 165 amp-hour silver-zinc 
battery (2 required for RIUS), a 25 amp-hour silver zinc battery and the 
power distribution and control circuits. An electrical power system 
schematic is shown in Figure 4. 3. 5-1. The 165 amp-hour battery (VPS) provides 
power for the Inertial Guidance System (IGS), ACS, communications equipment 
and instrumentation. The transient battery system (TPS) provides the power 
for transient loads such as the hydraulic motor, pyro circuits and solenoids 
to isolate the noise generating loads from the critical power buses. 

While attached, the Orbiter provides power to operate the IUS. The IUS is 
transferred to internal power just prior to deployment. 
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Table 4.3.3-2. /US Uplink Command List Summary 

NORMAL ENABLING AND SAFING COMMANDS 
Activate Mission Timing 
Open/Close TPS MDS 
Safe Main Propulsion System 
Open Propellant Dump Valves 
Close Propellant Prevalve and Dump Valves 
Pressurize Tanks to 20 psi 
Inhibit ACS 

Safe ACS Propulsion System 

Remove All I US Power 

Enable Ordnance and Main Engine Buses 

Safe Ordnance and Main Engine Buses 

Input Guidance Update Data 

Open/Close Propellant Line Cavity Vent 

OVERRIDE COMMAND FUNCTIONS 
Power to RF Amplifier On 
Power to RF amplifier Off 
Switchover to Backup Transmitter 
Switch Back to Primary Transmitter 
Turn On Instrumentation/Transmitter 
Turn Off Instrumentation/Transmitter 
Select Antenna Number 1, 2, 3, 4, 5 
. Inhibit Antenna Selector Search 
Enable Antenna Selector Search 
Ranging Channel Enable 
Ranging Channel Inhibit 
Disable Bang Bang Pressurization 
Arm Spacecraft Release 
Fire Spacecraft Release Ordnance 
Arm Kickstage Release 
Fire Kickstage Release .Ordnance 
Inhibit Spacecraft Release 
Inhibit Kickstage Release 
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IUS OPERATIONAL INTERFACES 


The IUS interfaces with the Orbiter, ground and Spacecraft during its 
prelaunch and flight operations. This section will discuss the external 
flight operations interfaces required by the IUS, with special emphasis 
on the IUS/.Orbiter interfaces and operations. 

5.1 IUS/ORBITER INTERFACES 

One of the major operational interfaces for the IUS is with the Orbiter 
during predeployment and deployment operations. Previous sections have 
given the Orbiter/IUS interface requirements and the IUS baseline configura- 
tion. This section discusses the specific Orbiter/IUS interfaces to meet 
those operational requirements and the interfaces required.. 

5.1.1 Orbiter Payload Interface Support 

The Orbiter provides a wide variety of interface capability for the varying 
payloads it will be carrying. Figure 5. 1.1-1 gives an overview of the avionic 
interfaces available for payloads, such as the IUS, and the associated paths 
for the data. .As shown, the Orbiter provides interfaces for the following 
types of data which are useful to the IUS: 

• Engineering Data - 16 KBPS to the payload signal processor (PSP) 
and up to -5 channels of up to 64 KBPS each to the Payload Data 
Interleaver (PDI). 

• Command/Data Input - 8 KBPS (2 KBPS of information) command link 
from the PSP and GN&C data and discretes from the MDM. 

• Caution and Warning - input capability for hardware C&W signals to 
the C&W Electronics Unit. 

• Timing - timing- signals from the Orbiter Master Timing Unit (MTU). 

In additional, high data rate interfaces are available for scientific data, 
but these are not required for the IUS. Also, since it is unmanned, no voice 
interfaces are required. 

The Orbiter has allocated approximately 10K of 32 bit words in main storage 
and approximately ]8 KOPS for payload (IUS/Spacecraft) support in its general 
purpose computer. 

The Mission Specialist Station (MSS) and Payload Specialist Station (PSS) 
also have space available for IUS dedicated interface panels (See Figure 
5. 1.1-2) which shows potential placement of non-standard avionics to' support 
IUS operations. Figure 5. 1.1 -3 gives a schematic of the control display panel 
in the MSS which will support the EIUS operations. As shown., these C&D inter- 
faces include status, deploy operations, IUS commands, abort sequences and 
manual control of IUS elements. 
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Figure 5. 1. hi. Orbiter A vionics Functional Diagram for Payloads 
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5.1.2 EIUS/Qrbtter Interface Overview 


A top-level ElUS/Orbiter interface schematic is shown in Figure 5. 1.2-1. 

As shown, the interface adapter provides the elements for interface 
compatibility between the Or biter and EIUS. The Orbiter provides the 
same interface capability that will be provided for Tug, but the EIUS is 
not presently directly compatible with that interface. The interface 
adapter will eliminate Orbiter grounding problems in addition to providing 
compatibility element between vehicles. 

The EIUS receives data and commands from the Orbiter (or ground) that are 
routed to the EIUS command decoders for decoding and distribution. Telemetry 
(16 or 64 KBPS) is routed from the EIUS RMIS to the adapter. C&W parameters 
are hardwired to the Orbiter. 

The Orbiter can receive either 16 'KBPS through the Payload Signal Processor 
(PSP) and/or 0 to 64 KBPS through the Payload Data Interleaver (PDI). 

Commands are sent from the PSP at 2 KBPS or from the MDM. The Orbiter can 
also provide GN&C data to the EIUS at rates up to 1 MBPS. 

After deployment, the interface between the EIUS and Orbiter is a 2 KBPS 
command link and a 16 KBPS telemetry link which provides the EIUS safety- 
related parameter for near-vicinity operations. 

A more detailed breakdown at the C&W parameters and discrete command 
interfaces are shown in Figure 5. 1.2-2. As shown, approximately 91 dis- 
crete commands have been identified from the data provided by NASA for the 
IUS and deployment adapter. Thirteen C&W signals were identified and are 
discussed in- the following section. 

5.1.3 IUS Caution and Warning Description 

The existing definition of the IUS shows caution and warning, will consist 
of the following parameters. 

1. Propulsion 

- Oxidizer Tank Overpressures 

- Fuel Tank Overpressures 

- Helium Sphere Overpressure 

- ACS Tank Overpressure 

2. Avionics 

- IMU Malfunction 

- Computer Alarm 

- Inadvertent Power On 

3. Inadvertent Disconnection 

- Propellant Dump Lines 

- Vehicle Holddown 

- Electrical Umbilical 
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4. Leak Detection 

- Oxidizer Vapor 

- Fuel- Vapor 

Propulsion - Each of the propellant tanks has an upper limit pressure switch. 

If the pressure exceeds the switch point, a light will appear on the* Orbiter 
caution and warning panel for the appropriate tank. The first action would be 
to verify the overpressure condition by calling up the corresponding tank 
pressure transducer on the vehicle instrumentation system. Once verified 
the corrective action would be initiated. For the fuel and oxidizer tanks, 
pressure would be relieved or propellants dumped by opening and closing the 
appropriate prevalve. This action would be initiated from the Orbiter at the 
MSS panel. For the helium spheres, pressure would be relieved by Orbiter _ 
command through the emergency vent valve. On the ACS tank, the only condition 
that would be expected to produce a pressure rise is a thermal input, and the 
ACS tank can withstand a worst-case temperature of 200 F (93'C) and still 
maintain a safety factor of 1.75. Hydrazine is a very stable monopropellant 
and contaminants that may produce decomposition would be detected on the 
ground during the 10-day period after propellant loading. 

Avionics - In the avionics system, failure modes exist that would ultimately 
constitute a safety hazard. The Inertial Measurement Unit (IMU) platform 
malfunction would be indicated by warning discretes indicating loss of platform, 
reference. The computer alarm indicates that the computer has failed a hardware 
especially pyrotechnic power, could constitute a safety hazard during pre- 
deployment checkout operations. The corrective action for any of the avionics 
failures is to remove Orbiter power to the IUS by guidance shutdown on the 
control and display panel. Each system will have redundant monitors to verify 
the failure prior to aborting the mission. 

Inadvertent Disconnection - Inadvertent separation of the propellant dump lines 
and vehicle IUS from the cradle is monitored by microswitches. These switches 
will be used to check for inadvertent separation on the electrical umbilical 
will be monitored by electrical continuity. Spacecraft separation from the 
IUS could be monitored on the same electrical circuit and in a similar manner 
to the vehicle separation by an AND/OR gate. The corrective action during the 
flight could vary from do nothing to EVA, or abort depending on the time of 
occurrence. 

Leak Detection - Leak detection for fuel and oxidizer was divided into two 
catagories— Cl) Detection during prelaunch when an atmosphere exists and 
(2) Detection under the vacuum environment of flight. 

Leak detection during prelaunch can be accomplished by standard commercial 
Units. These units operate in conjunction with a reference atmosphere and 
indicate vapor concentrations in parts per million. Separate probes would be 
used for fuel and oxidizer detection. The probes would be placed at such 
critical locations as the engine compartment and forward tank dome area or in- 
the exhaust purge- ducts on the Orbiter, 

It is recommended that a "Battery Temperatury Excessive" measurement be added 
to cover the possibility that an internal short can cause heating and rupture. 
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5.1.4 El U5/0rbi ter Operational Interactions 

The Orbiter will monitor the EIUS C&W safety related parameters to assure Orbiter 
crew safety and provides the switching capability to correct any detected 
malfunctions. These safety parameters are monitored and controlled while the 
EIUS is in the Orbiter bay or in the near vicinity of the Orbiter. 

The Orbiter will provide the capability to initiate safety or deployment criti- 
cal functions during EIUS deployment, and will monitor the results of those 
actions to assure the events have been accomplished. The critical activation 
items include power transfer, communications activation, and ACS activation. 

The Orbiter will control all mechanisms, such as latches and umbilicals, which 
relate to deployment. 

The Orbiter will monitor the status of safety or mission critical subsystems to 
assure mission accomplishment; however, the detailed EIUS status will be the 
prime responsibility of the ground. Corrective commands, which are not safety 
critical, will be issued by the ground and routed through the Orbiter for EIUS 
malfunction and contingency operations, 

5.2 IUS/GROUND CONTROL INTERFACE 

The IUS interfaces with the ground control center both while it is attached 
to the Orbiter and after deployment. Figure 5, 2. 0-1 gives an overview of the 
lUS/ground operations interfaces for both the attached and detached configuration. 
The IUS interfaces with ground control through either a 16 or 64 KBPS telemetry 
link which provides the operational and status data required for ground support 
operations. A 2 KBPS (information) uplink command capability provides any 
command or updates required for contingency operations. A more detailed 
discussion of the ground support for IUS is included in later sections. 

5.3 IUS/SPACECRAFT INTERFACE 


The IUS provides a limited interface with attached spacecraft because limited 
IUS capability exists to support the Spacecraft, as shown in Figure 5. 3. 0-1. 

The IUS provides the capability of routing external commands, (2 KBPS or 
discretes) through the IUS command decoders to the Spacecraft or by issuing 
IUS computer generated commands through the electrical sequencing, system. Some 
commands for the Spacecraft, such as IUS/Spacecraft separation and Spacecraft 
activation, are issued by the IUS. Some capability may exist to monitor 
parameters and provide commands as required. However, presently the inter- 
face capability does not exist in the IUS computer and the Spacecraft philosophy 
is to minimize these interactive interfaces, so this capability will be minimal 
or non-existant. Some spacecraft telemetry (10 KBPS maximum spacecraft require- 
ment) can be multiplexed into the IUS 16 or 64 KBPS telemetry stream by using an 
IUS remote Multiplexer to gather S/C data as inputs to the IUS RMIS. 

5.4 IUS/GSE INTERFACE 

The IUS interfaces with ground support equipment (GSE) during the prelaunch 
phase. The GSE interfaces with toe IUS interface adapter (See Figure 5. 1.2-1) 
much the same as the Orbiter. The GSE interface is used primarily for data 
transfer and status evaluation during the time just prior to launch. 
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IUS/SC IN ORBITER PAYLOAD BAY 


Figure 5.2.0-1. I US/Ground Interface Schematic 




IUS/SC OUTSIDE ORBITER RAYLOAD BAV 













Figure 5.3.0-1. I US/Spacecraft Avionic Interface 
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EIUS DEPLOYMENT OPERATIONS 



An analysis of the EIUS operations between the Orbiter launch and the EIUS 
initial main engine burn was conducted to evaluate the EIUS predeploy and 
post-deploy requirements. This section of the report will discuss the EIUS 
operations during these phases. 

6.1 ANALYSIS OVERVIEW 

6.1.1 Study Flow 

The deployment operations analysis was oriented to the activation and checkout 
functions to be performed during the phase. The items analyzed were the 
operational checkout philosophy, the activation and checkout functions and 
allocations and the impacts of the checkout, specifically for the Orbiter 
operations and software. The study flow is shown in Figure 6. 1.1-1. The EIUS 
system design, operations and checkout requirements were reviewed, assumptions 
were made to cover any gaps, and the on-orbit checkout goals were defined. 

These items were used as a basis for the development of a recommended checkout 
philosophy for the EIUS. The functions and operations to be performed for the 
predeploy and post-deploy operations were analyzed. The activation and check- 
out sequences were analyzed and allocation of functional tasks during these 
sequences was performed. The Orbiter functions were defined and software 
sizing estimates made to determine the Orbiter impacts. 

6.1.2 Definititins 

The definition of the primary terms used in the EIUS activation and checkout 
analysis is as follows: 

• Predeploy Operations - those operations performed after 
the Orbiter launch and through the time of release of the 
EIUS by the Orbiter Remote Manipulator System (RMS). 

• Post-deploy Operations - those operations performed after 
release of the EIUS by the RMS until the EIUS is readied for 
its initial main engine burn. 

t Status Monitor - the routine assessment of the EIUS telemetry 
stream to determine the health -of the EIUS and its subsystems. 

• Checkout - the exceptional effort to determine -the health of a 
component or system by issuing a command or stimulus and 
monitoring the response. 

• Operational Monitor - the monitoring of operational data during 
periods when the system is operating. 

• Activation Monitor - the monitoring of parameters or conditions 
activated or initiated when components or subsystems are being 
turned-on and readied for operation. 
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• Prime Responsibility - denotes the element responsible for 
initiating or monitoring functions and making decisions 
involving those functions. 

• Backup Responsibility - denotes the element which provides 
the backup capability to initiate or monitor function and 
make decisions involving those functions should the primary 
element become in operative. 

6.2 REQUIREMENTS, GROUNDRULES AND ASSUMPTIONS 

6.2.1 Requirements 

The requirements used as the baseline for this study were the requirements 
given in Section 2.0, which were derived from those in SR-IUS-100. The 
requirements which apply to on-orbit operations were used. 

The only requirement that did not appear to be met for on-orbit checkout 
operations is as follows: • • ■ 

"3.1.9 Systems Verification (SR-IUS-100) 

The IUS system shall verify the ability of the IUS to 
perform its mission at a time after Orbiter ascent, but 
prior to deployment." 

The baselined design of the IUS limits the computer status monitoring to 
the IMU, computer and flight control subsystems. The IUS only verifies 
selected IUS. elements and either the ground or Orbiter would be required to 
aid in the total verification of the IUS prior to deployment to perform its 
mission. No serious operational impacts are defined as a result of this 
exception. 

6.2.2 Groundrules and Assumptions 

The following groundrules or assumptions were made to supplement the require- 
ments discussed previously. 

• An Expendable IUS was baselined for the study. The Reusable 
IUS and its associated recovery operations was not addressed. 

• The EIUS is baselined to be basically autonomous with command 
capability available from the ground (or Orbiter) for contingencies. 

• From a review of the EIUS design, limited onboard self- test 
and redundancy management is available. 

• The analysis includes on-orbit operations prior to the EIUS 
initial main engine burn. 

• The EIUS is operational in the vicinity of men in the Orbiter, 
therefore, vehicle safety is imperative. 
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6.3 EIUS REDUNDANCY AND SELF TEST SUMMARY 

The. EIUS configuration was analyzed to determine the component redundancy 
level, component/function capabilities, and self-test capabilities to provide 
a basis for the operations analysis concept development. 

The major EIUS components (or subsystems) are shown in Table 6. 3.0-1. The 
table indicates the redundancy level, backup capability and function for each 
component or subsystem. The asterisks indicate which EIUS components or 
subsystems are critical to the success of the EIUS mission. As the chart 
shows, most of the components are simplex with little redundancy available, 
and no backup capability exists to support the component or component function. 
Therefore, little work-around capability exists in the event of an EIUS 
component or subsystem malfunction. 

The EIUS subsystem checkout capability summary is shown in Table 6. 3.0-2. The 
only major subsystem providing self-test is the IMU/computer which uses self- 
test software to evaluate the GN&C subsystem status. The flight control 
actuators and ACS provide a capabil ityfor a command/.response type test, but 
because of safety considerations, this is practical only after deployment and 
a safe separation distance is achieved by the Orbiter. Other EIUS subsystems 
work basically by monitoring status and'-operational measurement (by Orbiter 
or ground) and comparison of values with expected values. 

There are some conclusions which can be drawn from these charts. First, to 
enhance mission success probability, the EIUS mission must be performed in 
as short of a time as possible to decrease the probability of a critical 
component failure. Secondly, the checkout capability summary indicates that 
very little capability exists to checkout the EIUS prior to deployment. Since . 
the redundancy is limited, predeployment checkout should be limited to assessing 
the proper IMU/computer operations and waiting until after separation and the 
Orbiter is a safe distance from the EIUS to verify the operation readiness of 
the ACS and main propulsion system. 

6.4 CHECKOUT GOALS AND PHILOSOPHY 

For the deployment operations, goals were established to provide a basis for 
the checkout concepts and philosophy. A philosophy was then established 
which outlined the primary approaches to EIUS on-orbit checkout and the 
responsibilities for each supporting element. 

6.4.1 Goal s .» 

The following goals were established as guidelines for the development of the 
EIUS on-orbit checkout concepts and philosphy: 

• The reason for deployment operations was to provide an 
indication of the EIUS prior to major mission events, _ 
specifically, prior to deployment and prior to the initial 
EIUS main engine burn. 

• Since the EIUS was designed for a short duration mission, 

any increased mission time due to checkout should be minimized 
or eliminated. 
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Table 6.3.0-1. EIUS Operational Redundancy Summary 


COMPONENT/SUBSYSTEM 

REDUNDANCY 

BACKUP 

FUNCTION 

*IMU 

SIMPLEX 

— 

INERTIAL ATTITUDE REFERENCE 

COMPUTER 

SIMPLEX 

— 

ON-BOARD CONTROL AND 
PROCESSING 

RMIS (TELEMETRY) 

BASICALLY SIMPLEX 

— 

TELEMETRY DATA ORGANIZATION 

^BATTERIES (2) 

SIMPLEX 

— 

POWER GENERATION 

COMMUNICATIONS 

BASICALLY DUAL 
REDUNDANT 

— 

ORBITER, GROUND INTERFACE 

^ATTITUDE CONTROL 
PROPULSION SYSTEM 

BASICALLY DUAL 
REDUNDANT 

— 

ATTITUDE CONTROL, 
LOW LEVEL THRUST 

*MAIN PROPULSION 
SYSTEM 

SOME REDUNDANCY 

— “ 

HIGH ENERGY THRUST 

*SYSTEMS MANDATORY FOR EIUS 

OPERATION 






Table B.3.0-2. £ I US Subsystem Checkout Capability Summary 


COMPONENT/SUBSYSTEM 

CHECKOUT CAPABILITY 

IMU/COMPUTER 

CONSIDERABLE SELF-TEST ‘CAPABILITY IN 
COMPUTER SOFTWARE 

FLIGHT CONTROL SYSTEM 

COMMAND ACTUATORS, AND ACS - MONITOR 
RESPONSE (ORBITER/GROUND) 

OTHERS 

MONITOR MEASUREMENTS AND COMPARE 
(ORBITER/GROUND) 




■ The Orbiter involvement should be minimized to decrease, the 
operational complexity between the EIUS and Orbiter. 

• Since the Orbiter is a manned space vehicle, any potential 
Orbiter safety impacts due to checkout should be minimized 
or eliminated. 

• Effective use of the EIUS onboard capability to support 
deployment operations should be accomplished. This would 
reduce external support requirements.’ 

• Any checkout concepts or philosophies considered should be 
cost-effective approaches. 

• The ground control involvement should use cost-effective 
approaches which enhance mission success probability without 
undue cost or increased operational complexity. 

6.4.2 On-Orbit Checkout Philosophy 

Using the goals established above, a philosophy was developed which provides 
a logical operational solution to the need for verification of the EIUS to 
perform its mission. A summary of the philosophy is shown in Table 6.4. 2-1. 

The major emphasis for the EIUS checkout is to minimize the EIUS mission time 
prior to the EIUS initial main engine burn and to utilize the status, activation 
and operational data, rather than interactive checkout results to determine 
the EIUS health. It is assumed that the design of the EIUS involves status 
and operational parameters which most aptly describe the condition of the EIUS 
elements. The EIUS will perform as much as the activation and status veri- 
fication activities as feasible based on an existing design. 

Some EIUS components are active for the total EIUS mission, while others are 
not required until after Orbiter launch. To conserve power and enhance 
reliability, subsystems and components should be activated only when they are 
required for operation and it is proposed that only those mission critical com- 
ponent activated after deployment should have any interactive checkout. This 
minimizes the chances of any hazardous situations developing from activities 
with potential safety hazards. Since the EIUS is basically autonomous, 
sequences will be initiated and controlled by the EIUS onboard elements where 
possible. No nominal command or timeline activity is allocated to the ground 
for a nominal mission; however, in the event of a malfunction, contingency 
operations will be supported by the ground. 

The Orbiter controls all deployment operations for payloads and thus, for the 
EIUS deployment and any EIUS related deployment activities are controlled by 
the Orbiter. After deployment, the Orbiter will separate to a safe distance 
from the EIUS and will maintain its station to support contingency operations. 

No EIUS checkout support will be required after deployment, since the ground 
will become the prime support element after separation is achieved. 
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Table 6.4.2-1. E/US On-Board Checkout Philosophy 

t UTILIZE El US STATUS, ACTIVATION, AND' OPERATIONAL DATA FROM EIUS SUBSYSTEM 
STATUS ' 

• MINIMIZE MISSION TIME PRIOR TO DEPLOYMENT AND EIUS FIRST BURN 

• ACTIVATE SUBSYSTEMS/COMPONENTS ONLY WHEN REQUIRED FOR OPERATION 

• ‘ LIMIT EIUS CHECKOUT TO MISSION CRITIAL SUBSYSTEMS ACTIVATED AFTER DEPLOYMENT 

• NO PREPLANNED COMMAND ACTIVITY ALLOCATED TO GROUND 

t NO ORBITER CHECKOUT INVOLVEMENT AFTER DEPLOYMENT 

• GROUND INVOLVEMENT 

MONITORS STATUS, ACTIVATION, CHECKOUT AND OPERATIONAL DATA 
PROVIDES COMMANDS OR INHIBITS IF ON-BOARD EIUS MALFUNCTIONS OCCUR 

• ORBITER INVOLVEMENT 

MONITORS C&W SAFETY AND CRITICAL SUBSYSTEM PARAMETERS 
CONTROLS DEPLOYMENT OPERATIONS 

INITIATES SOME ACTIVATION AND BACKUP SEQUENCE INITIATION COMMANDS 
t EIUS COMMANDS ALL NON-C&W/ABORT EIUS SEQUENCING/FUNCTIONS 




The EIUS ground control personnel have the responsibility for monitoring, the 
telemetry data generated by the EIUS to evaluate the EIUS health and to make 
decisions based on that information. However, since the EIUS is basically 
autonomous, the ground will provide command or inhibit only if EIUS onboard 
malfunctions occur. The ground will make use of status, operational and 
activation data and if malfunctions occur while the EIUS is in or near the 
Orbiter* the ground will report any potential safety impacts to the Orbiter 
crew and recommend the appropriate remedies. 

The Orbiter crew has the responsibility for monitoring payload safety related 
parameters and the status of critical payload subsystems, and providing the 
capability for control of these elements during critical phases, safety related 
operations and deployment. This includes the activation of selected EIUS 
components/subsy stems during deployment. In addition, to enhance the probability 
of mission success and to prevent the loss of an EIUS or its mission objectives, 
the Orbiter will have the capability to initiate selected activation sequences 
and to provide more detailed backup sequence commands. This Orbiter onboard 
capability will be a backup to the ground which has prime responsibility for 
these commands if they cannot be accomplished by the EIUS onboard system. 

The EIUS, as mentioned previously, will provide the activation sequencing and 
checkout evaluation onboard if possible. The Orbiter must be able to control 
safety related elements and abort situations, but the EIUS is expected to 
command any non-C&W/abort sequences and/or functions which the EIUS requires. 

If the EIUS does not have sufficient capability to perform the function, they 
will be allocated to the ground or Orbiter. 

6.5 PRE-DEPLOY OPERATIONS 

The EIUS is attached to the Orbiter during prelaunch, launch and on-orbit prior 
to deployment by the Orbiter. This ’section discusses the on-orbit flight 
operations for Orbiter insertion until separation of the EIUS from the Orbiter. 
The items to be discussed include the EIUS activation sequence, flight operations 
allocation of functions, the command and monitoring responsibility summary and 
a general discussion of the operations during the phase. The EIUS timeline and 
missions- flows for this phase are discussed in Section 3.0. 

6.5.1 Component Activation 

The following EIUS components are active during launch and during the pre- 
deploy operations: 

Computer 

imu 

Remote Multiplexer Instrumentation System (RMIS) 

Command Decoders 

The computer and IMU are active to maintain an inertial attitude reference for 
the EIUS and must be activated on the ground. The RMIS provides telemetry data 
both to the Orbiter and ground to meet safety monitoring and status requirements 
while the command decoders are required for command interface with the EIUS to 
accomplish the mission and correct anomalies. 

Two EIUS subsystems are activated during this phase. These are: 

Batteries 

Communications 
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The batteries are activated (or utilization begun) just before Orbiter 
umbilical- disconnections. Since the umbilicals are disconnected prior to being 
deployed, the batteries must be activated during this phase. 

The EIUS communications are required to maintain continuous interface with the 
Orbiter for Orbiter Safety monitoring and for operational and contingency command 
interface. The communications are activated and verified just prior to Orbiter 
umbilicial connections. 

Since the ACS and main propulsion system are not required during this phase and 
since any partial activation could potentially lead to Orbiter safety impacts, 
they are inactive until after deployment. 

6.5.2 Flight Operations Function Allocation 

The proposed allocation of EIUS (and Orbiter) functions during the pre-deploy 
operations is summarized, in Table 6. 5. 2-1. The top level functions are shown 
and the function is allocated as prime (x) or backup (B/U) to either the EIUS, 
Orbiter or ground control. 

As shown, the EIUS does little but supply data and command certain onboard EIUS 
sequences such as vents and purges. It is active, however, performing its 
operational functions, such as navigation, IMU processing, and internal status 
monitoring. 

While the EIUS and Orbiter are attached, the Orbiter is prime for most safety- 
critical and deployment function, which are the majority of the functions 
included during this phase. The major Orbiter tasks are C&W monitor and 
control, EIUS state vector assessment and updates, deployment operations and 
activation of EIUS batteries and communications.- It also provides some backup 
capability for EIUS subsystem status monitoring and EIUS initiated 1 vents and 
purges. 

The ground control prime responsibility during pre-deploy operations is 
monitoring the health and status of the EIUS and providing Orbiter crew 
recommendations or corrective commands for malfunctions. The ground also 
provides backup capability for data comparisons, navigation updates, and 
selected sequencings if the Orbiter has problems performing its assigned 
functions. 

6.5.3 Command/Monitoring Summary 

The following list gives a summary of the types of data being monitored for 
major EIUS components during pre-deploy operations, where S = status data 
monitoring, 0 = operational data monitoring, C = checkout data, and A = 
activation data monitoring:- 

• Computer - S.O 

• IMU - S.O 

• RMIS - S, 0 

• Decoders - S,0 

• Batteries - S,A,0 

• Communications - $,A,0 

• ACS and MPS - S 
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Table 6.5.2-1. E/US Pre-Deploy Flight Operations Function Allocation 




ALLOCATION 


FUNCTION 

EIUS 

ORBITER 

GROUND 

C&W MONITOR 


X 

B/U 

EIUS STATUS MONITOR 


B/U 

X 

SAFETY CONTROL & MONITOR 


X 

X 

VENTS, PURGE 

X 

B/U 

B/U 

ORB ITER/EIUS IMU COMPARISONS 


X 

B/U 

NAVIGATION, ATTITUDE UPDATE 


X 

B/U 

DEPLOYMENT ADAPTER OPERATIONS 


X 


RMS OPERATIONS 


X 


BATTERY ACTIVATION/POWER TRANSFER 


X 

B/U 

COMMUNICATIONS ACTIVATION 


X 

B/U 

ORBITER/EIUS RF VERIFICATION 


X 



ORIGINAL PAGE IS 
OP POOR QUALITY 



The main types of data being generated are the status parameters and operational 
data and results and they are the prime means of obtaining and evaluating EIUS 
health. The activation parameters are useful in assessing the correct operation 
of the batteries and communications. No interactive checkout is required during 
this phase. 

Table 6. 5. 3-1 gives an overview of the specific data or task allocated to either 
the EIUS, Orbiter, or ground control during pre-deploy operations for each of 
the data types shown above. 

The EIUS monitors the status of critical EIUS subsystems, such as the computer 
and IMU, of selected activation command responses, and of all operational data 
pertinent to proper EIUS controlled operations. Since EIUS commands and sequences 
are internally generated, the external command/update list is not applicable. 

The Orbiter monitors C&W parameters, critical EIUS status parameters and other 
safety parameters, during both activation and communications link verification 
to assure Orbiter safety. In addition, the Orbiter assesses the EIUS state 
vector and provides updates if required. The Orbiter is required to command the 
power transfer, any navigation or attitude updates, and communications activation 
for the EIUS. 

The ground monitors all telemetry generated by the EIUS and provides the command 
capability for target updates or activation sequencing if required. 

6.5.4 Operations Description 

After Orbiter launch, the EIUS status, C&W and safety parameters are monitored 
continuously by the ground and/or Orbiter. After any vents or purges are 
accomplished, the Orbiter will compare the EIUS state vector and attitude with 
the same Orbiter parameters and will provide navigation or attitude update para- 
meters to the EIUS if the dispersion are above expected tolerances. 

After the Orbiter second burn, the Orbiter will begin deployment operations by 
switching the EIUS from Orbiter to internal batteries and will process with the 
deployment sequence. Just prior to umbilical disconnection, the EIUS communica- 
tions will activate and the command link verified. The EIUS will then be dis- 
connected from the Orbiter and released by the Orbiter remote manipulator system. 

6.6 POST-DEPLOY OPERATIONS 

The pre-deploy operations begin with release of the EIUS by the Orbiter until 
the EIUS has been activated and readied for its first main engine burn. This 
section discusses the activation sequence, flight opeations allocation of 
functions, the command and monitoring responsibility summary and a general 
discussion of. the operations during the phase. The timelines and flows for this 
phase are discussed in Section 3.0. 

6.6.1 Component Activation 

All EIUS subsystem or components except the ACS and main propulsion system are 
activated prior to deployment by the Orbiter since they are required for 
operation prior to deployment. 


6-12 



6-13 


Table 6.5 r 3-1. .EIUS Pre-Deployment Command /Monitoring Function Allocation 


FUNCTION DATA/TASK ALLOCATION 




EIUS 


ORBITER 


GROUND 

STATUS MONITORING 

• 

CRITICAL SUBSYSTEM 

• 

C&W PARAMETERS 

• 

ALL PARAMETERS 



STATUS 

t 

SAFETY PARAMETERS 






• 

CRITICAL SUBSYSTEM 
STATUS PARAMETERS 



OPERATIONAL MONITORING 

• 

ALL OPERATIONAL DATA 

• 

EIUS/ORBITER IMU 

• 

ALL TM DATA 



TO COMPUTER 


COMPARISONS 



ACTIVATION MONITORING 

• 

SELECTED CRITICAL 

• 

SELECTED SAFETY 

• 

ALL TM DATA 



PARAMETERS 


PARAMETERS 



CHECKOUT MONITORING 


— 

• 

SELECTED SAFETY 
PARAMETERS 

• 

ALL TM DATA 




• 

COMM LINK VERIFICATION 



EXTERNAL COMMANDS/UPDATES ' 


N/A 

• 

POWER TRANSFER 

• 

TARGET UPDATE 
(IF REQUIRED) 




• _ 

NAVIGATION, ATTITUDE, 
UPDATES 

• 

BACKUP FOR 
ACTIVATION 
SEQUENCING 


NOTES: OPERATING DURING PHASE - COMPUTER, IMU, RMIS, DECODERS 

BEING ACTIVATED DURING PHASE - BATT. COMM 
INACTIVE SYSTEMS MONITORED DURING PHASE - ACS, MPS 



The ACS is partially activated just after separation from the Orbiter to allow 
the EIUS to maintain an attitude hold at its separation attitude to prevent 
Orbiter recontact until the Orbiter is a safe distance from the EIUS. After 
the distance is attained, the total EIUS ACS will be activated to allow attitude 
maneuvers required for proper operation of the EIUS. The main propulsion system 
(MPS) or main engine is also deactivated, for safety reasons, until after a safe 
Orbiter separation distance is attained. The MPS is then activated and brought 
to its operational capability prior to its initial burn. 

6.6.2 Flight Operations Function Allocation 

The recommended allocation of functions to the EIUS, Orbiter or ground control 


>ost-deploy operational functions 

are as 

follows : 




.Allocation 


Function 

EIUS 

Orbiter 

Ground 

ACS Initial Activation 


X 

B/U 

C&W Monitor 


X 

B/U 

EIUS Status Monitor 



X 

ACS Final Activation 

X 


B/U 

MPS Activation 

X 


B/U 

Target Update (if required) 



X 


. The prime responsibility is denoted by (X) and the back-up responsibility by (B/U). 

As shown, the Orbiter activates the EIUS ACS immediately after separation and 
monitors the C&W parameters until a safe separation distance is attained. The 
Orbiter then is on a stand-by status for possible contingency operations. The 
EIUS has the responsibility of ACS final activation and MPS activation after 
Orbiter separation. 

Ground control monitors the EIUS telemetry for status, safety and operational 
readiness and provides backup capability as required for contingency sequences or 
updates, such as target update. 

. 6.6.3 Command/Mon i tori ng Summary 

The following list gives a summary of the types of data being monitored for major 
EIUS components during post-deploy operations, when S = status data monitoring, 

0 = operational data monitoring, C = checkout data, and A = activation data 
monitoring: 

• Computer - S, 0 

• IMU - S, 0 

• RMIS - S, 0 
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• Decoders - S, 0 

• Batteries - S, 0 

• Communications - S, 0 

• ACS - S, A, 0 

• MPS - S, A, 0, C 

The main types of data being generated are the status parameters and operational 
data and are the prime means of assessing onboard EIUS health. For instance, 
if the vehicle performs its maneuvers properly, the computer, 1MU and ACS are 
probably operating properly. The ACS and MPS activation data and results also 
give an indication of their health and proper operation. The only candidate for 
checkout is the MPS. Some MPS values could be checked or the MPS hydraulics 
manipulated, however, since mission time is limited, very little, if any, MPS 
checkout will be performed. 

An overview of the EIUS post-deploy specific data or task allocation of command 
and monitoring functions is shown in Table 6. 6. 3-1. These functions were allocated 
to the EIUS, Orbiter, or ground. 

The Orbiter functions begin to decrease after separation. It has the responsi- 
bility of commanding ACS activation and is backup for contingency safety related 
commands. It monitors the EIUS C&W and critical subsystem parameters and the EIUS 
attitude to avoid collisions with the EIUS. After a safe separation distance is 
achieved, the Orbiter is no longer responsible for active EIUS operations parti- 
cipation. 

The EIUS assumes the prime operational responsibility after separation for 
monitoring the status and operational data required for effective EIUS 
operations. The ground monitors the EIUS telemetry and provides the capability 
for malfunction detection and analysis and corrective command action for contin- 
gencies. The EIUS operates autonomously after separation unless inhibited from 
doing so by the Orbiter or ground. 

6.6.4 Operations Description 

After release of the EIUS by the Orbiter RMS, the Orbiter activates the EIUS ACS 
to an attitude hold mode, monitors C&W, safety and EIUS attitude data and maneuvers 
to a safe separation distance from the EIUS. The EIUS then begins its nominal 
mission sequence by activating or releasing inhibits from the ACS and MPS controls 
and by fully activating those subsystems, and performing any required or desired 
attitude maneuvers. After the operational verification has been established, the 
EIUS is ready to begin the main engine pre-ignition sequencing required for its 
initial burn. 

6.7 ORBITER IMPACTS SUMMARY 

An assessment of the Orbiter impacts based on the results of the deployment 
operations was made to determine if potential Orbiter support problems exists. 

This section gives a discussion of the Orbiter operational support functions for 
the EIUS which would impact Orbiter software and a computer/software sizing 
estimate to support those functions. 
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Table 6.6.3-1. EHJS Post-Deployment Command /Monitoring Function Allocation 


FUNCTION 



DATA/TASK ALLOCATION 





'EIUS 

ORBITER 


GROUND 

STATUS MONITORING 

• 

CRITICAL SUBSYSTEM 
STATUS 

• C&W PARAMETER 

• SAFETY PARAMETERS 

• 

ALL PARAMETERS 

OPERATIONAL MONITORING 

§ 

ALL OPERATIONAL DATA 
TO COMPUTER 

• EIUS ATTITUDE 

• 

ALL TM DATA 

ACTIVATION MONITORING 

• 

SELECTED CRITICAL 
PARAMETERS 

— 

• 

ALL TM DATA 

CHECKOUT MONITORING 

• 

SELECTED STATUS 
PARAMETERS 

— 

• 

ALL TM DATA 

EXTERNAL COMMANDS/UPDATES 


N/A 

• • INITIAL ACS 
ACTIVATION 

• 

BACKUP FOR ACTI- 
VATION SEQUENCES 




• CONTINGENCY SAFETY 
RELATED COMMANDS 

§ 

PROGRAM INHIBITS 
IF MALFUNCTIONS 

NOTES: OPERATING CONTINUOUSLY 

BEING ACTIVATED DURING 

DURING 
PHASE - 

PHASE - COMPUTER, IMU, 
ACS, MPS 

RMIS , DECODERS, BATT, COMM 





6.7.1 Operations Support Functions Description 

The Orbiter functions required to support the EIUS on-orbit flight operations 
are summarized in Table 6. 7. 1-1. Since -the Orbiter is required to monitor 
selected EIUS safety and status parameters, the Orbiter must process the EIUS 
telemetry data stream to the Orbiter (16 KPBS) and retrieve the data parameters 
required for analysis. After the correct C&W, safety and status parameters are 
selected, the Orbiter will compare those parameters with the expected results or 
limits and store the data for future display by the Orbiter C&D as required. 

The Orbiter will also monitor the operational status of all EIUS mission 
critical components as a basis for operational impacts. Any anomalies detected 
by the Orbiter will be evaluated and, if necessary, corrective command control 
active will be taken to alleviate the anomaly or correct the problem. 

The Orbiter is al.so required to initiate or support selected EIUS activation _ 
or operational support sequences while the EIUS is attached or in close proximity 
to the Orbiter. These functions include power transfer, EIUS communications 
activation and verification, ACS initial activation, EIUS navigation, attitude 
or target updates, and the evaluation of the EIUS state vector to determine if 
updates are required. These support functions are included in the nominal mission 
timeline. 

For the activation initiation, commands would be sent and results' obtained and 
evaluated to determine if satisfactory results were obtained. The EIUS state 
vector evaluation would be more complex with the comparisons evaluated, and 
updates initiated if required. 

The Orbiter will also provide some capability to support contingency operations 
associated with the EIUS, such as abort sequencing, subsystem activation actua- 
tion sequencing, vents and purges. These functions would only be required for 
contingency operations and could either be hardwired or commanded through the 
RF link. Except for abort sequencing, which is a prime Orbiter function, most 
of the contingency activation sequencing is backup to both the EIUS and ground. 

The Orbiter also provides operations support for the EIUS when the vehicle or 
subsystems are not actively involved in the operations. Examples of .these, 
types of functions include remote manipulator operations, communication switching 
and recording of EIUS telemetry and commands, deployment operations and collision 
avoidance computations. These items may not be charged to the IUS/Spacecraft, 
but are defined as necessary to support EIUS operations. 

6.7.2 Computer/Software Impacts 

The basic Orbiter/EIUS on-orbit operations philosophy was to perform as many of 
the required software functions in the EIUS as possible, which would mean that 
the Orbiter would only initiate sequences which would be performed by the EIUS. 
This is especially true for the activation sequencing. This section reviews 
the Orbiter software functions sized to support the EIUS. Functions to support 
the Spacecraft were not sized. 
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Table 6.7.1 -1. Orb iter Operations Functions to Support El US 


• 

SAFETY/STATUS MONITORING 


- 

EIUS TELEMETRY PROCESSING (16 KBPS) 


- 

C&W/SAFETY PARAMETER MONITORING CONTROL 


- 

SELECTED EIUS SUBSYSTEM STATUS MONITOR/CONTROL 

• 

El US 

ACTIVATION/OPERATION SUPPORT 



IMU STATE VECTOR COMPARISONS 


- 

POWER TRANSFER 


- 

NAVIGATION, ATTITUDE AND TIMING UPDATES 


- 

COMMUNICATIONS ACTIVATION AND VERIFICATION 


- 

ACS INITIAL ACTIVATION 

• 

CONTINGENCY SEQUENCING SUPPORT _ 



ACTIVATION ACS, MPS, BATT, COMM 


- 

PROPELLANT DUMP, VENTS AND PURGES 


- 

ABORT SEQUENCING 

t 

MISCELLANEOUS ORBITER SUPPORT 


_ 

DEPLOYMENT OPERATIONS 


- 

REMOTE MANIPULATOR OPERATIONS 


- 

COMMUNICATION SWITCHING/RECORDING MANAGEMENT 


- 

EIUS ATTITUDE-COLLISION AVOIDANCE MONITORING 



6. 7. 2.1 Sizing Summary 

A summary of the Orbiter software storage impacts to support the EIUS operations 
are given in Table 6. 7. 2-1. The functions to be sized were discussed in the 
previous section, and are divided into two groups, Orbiter interactive support 
for EIUS and Orbiter controlled support for EIUS. The interactive support includes 
the interactive ElUS/Orbiter interfaces and operations, and include EIUS safety/ 
status monitoring,' EIUS subsystem activation and operations support, and backup 
or contingency sequencing support. The Orbiter controlled support includes overhear 
to the Orbiter operating system (OS) and EIUS displays and controls in the MSS, 
and miscellaneous support provided to the EIUS such as remote manipulator, 
communications and deployment adaptor operations which are done independent of 
EIUS involvement. Some of the Orbiter controlled support may not be charged to 
the EIUS. 

The sizing assumes that a 75% short and 25% long mix for both instructions and 
data is used to obtain the total Orbiter storage requirements. The Orbiter is 
baselined with a 32 bit word length for storage. The summaryin Table p.7.2-1 
indicates that approximately 1 OK of 32 bit words is required in the Orbiter 
DMS, assuming that both interactive support and Orbiter controlled support are 
charged to the EIUS. But, since only a portion of the total storage is required 
at any one time, only about 1.7K of 32 bit words is required in main storage at 
one time. Therefore, the EIUS required software can be stored in the Orbiter mass 
storaqe and called into main memory when required for operations. The major 
Orbiter storage impacts are for EIUS display formats and data (8 formats assumed) 
which will be displayed in the Orbiter for safety and status monitoring. The 
functions sized have extremely low execution rates, and .when coupled with low 
instruction numbers, a minimal speed impact to Orbiter is expected. The Orbiter 
support requirements appear to be well within the support capability of 10K and 
18 KOPS provided to payloads by the Orbiter. 


6.7. 2. 2 Interactive Support 


The interactive support sizing details include safety/status monitoring, 
activations/operations support, and contingency sequencing support, and are 
shown in Tables 6. 7. 2-2 through -4. 


The safety/status monitoring support (Table 6. 7. -2-2) lists the items sized. The 
16 KPBS telemetry stream from the EIUS is processed by the Orbiter to select the 
estimated 80 (of about 210 total EIUS) telemetry parameters which would be used by 
the Orbiter for IUS safety and status monitoring. The .parameters requiring limit, 
status, or ao/no-go checks are processed by the Orbiter computer for anoma y 
reporting, "the EIUS data will be grouped into display formats and associated 
display parameters for display use 'by the MSS personnel. Eight displays are 
assumed and the display format (or display background) and the mapping tables, 
which select the parameters to be displayed on the format, were included in the 
sizing. As shown, the display images (or formats.) are the main storage impacts, 
with a total storage requirement of a little more than 4K of 32 bit words. 

The activation and operations sequencing by the Orbiterto support the EIUS 
(Table 6. 7. 2-3) are the power transfer, ACS initial arming, communications 
activation and verification, and EIUS state vector comparison and update. The 
commands are in tables which contain the command address, time of issuance, 
sequence dependency, verification response from the EIUS and error processing 
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Table 6.72-1. Orbiter Software Sizing to Support EIUS 


MAX MAIN 


INTERACTIVE SUPPORT FOR EIUS 

INST 

DATA 

*T0TAL 
(32 BIT 
WORDS) 

MEMORY 
(32 BIT 
WORDS) 

SAFETY/STATUS MONITORING 
ACTIVATION/OPERATIONS 

350 

6,195 

4,091 

1,031 

SUPPORT 

CONTINGENCY SEQUENCING 

900 

300 

750 

219 

SUPPORT 

1,900 

1,375 

2,047 

” — 

SUBTOTALS 

ORBITER CONTROLLED SUPPORT 
MSS SUPPORT SOFTWARE 

3,150 

7,870' 

6,888 

1,250 

(OVERHEAD) 

MISCELLANEOUS ORBITER 

400 

280 

425 

.425 

SUPPORT 

2,700 

1,950 

2,907 

“ — 

SUBTOTALS 

3,100 

2,230 

3,332 

425 


^ASSUMES 75% SHORT AND 25% LONG INSTRUCTION AND DATA MIX . 
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Table 6.7. 2-2. Safety /Status Monitoring Sizing 


FUNCTIONS 

INSTRUCTIONS 

DATA 

TOTALS 

(32 BIT WORDS) 

TELEMETRY STREAM PROCESSING 
(16 KBPS)* 

250 

650 

563 

LIMIT TESTING/STATUS CHECKING 

100 

25 

: 78 

DISPLAY IMAGES (8 IMAGES @600 
WORDS/DISPlAY) 

— 

4,800 

3,000 

DISPLAY MAPPING TABLES (8 IMAGES 
• X [6 WORDS/IMAGE ENTRY X 15 ENTRIESJ ) 

— 

720 

450 

TOTALS 

350 

6,195 

4,091 

*BASED ON AN ESTIMATED SO TELEMETRY PARAMETERS TO BE MONITORED 
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Table 8. 7,2-3. Activation /Operations Support Sizing 


FUNCTIONS 

INSTRUCTIONS . 

DATA 

(32 BIT 

POWER TRANSFER 

200 

70 

169 

ACS ARMING 

250 

80 

206 

UPDATE GN&C PARAMETERS (*) 

200 

50 

156 

COMMUNICATION ACTIVATION/ 
VERIFICATION 

250 

100 

219 


TOTALS 


TOTALS 


(*) INCLUDES: (1) COMPARISON OF ORBITER/IUS NAVIGATION/ATTITUDE; (2) NAVIGATION/ATTITUDE UPDATES 
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Table 6.7. 2-4. Contingency Sequencing Support Sizing 


FUNCTIONS 

MISSION SEQUENCE START 
ACS ACTIVATE 
MPS ACTIVATE 


INSTRUCTIONS 

50 

200 

200 


VENTS/PURGES 500 

ABORT SEQUENCING 750 

BATTERY ACTIVATION 200 

TOTALS 1,900 


DATA 


TOTALS 

(32 BIT WORDS 


25 

47 

150 

219 

150 

219 

250 

468 

650 

875 

150 

2l9 


1,375 


2,047 






indication, if required. The GN&C update capability will provide an evaluation 
of the EIUS state vector to determine the need for an update and to provide the 
updates if required. Only about 750 words -.are required for these items. 

The contingency sequencing support (Table 6. 7. 2-4) provides backup activation 
or sequencing capability to support the EIUS. The items sized include a more 
detailed activation/operation sequence than required for normal operations and 
would be used only if EIUS (or ground) operation were not feasible. The abort 
sequencing is controlled only by the Orbiter, but was included in the contin- 
gency support since it is not required during normal on-orbit operations. Ap- 
proximately 2K of storage is required for the contingency sequencing support. 

6. 7. 2. 3 Orbiter Controlled Support 

The functions sized for Orbiter controlled support do not interface with the 
EIUS, but provide support for EIUS operations. These include MSS support soft- 
ware and miscellaneous Orbiter support. The sizing impacts are shown, respec- 
tively, in Tables 6. 7. 2-5 and 6. 7. 2-6. 

The MSS support software (Table 6. 7. 2-5) includes function/phase initialization 
and tables for the Orbiter computer operating system input/output utilization 
The function/phase initialization sizing includes the selection of displays, 
responses to keyboard entries, priority assignments and loading data from mass 
storage. The I/O table includes items the Orbiter OS must support, such as a 
valid command tables and display linkage tables. The Orbiter storage impact 
is 425 words. 

The miscellaneous support (Table 6.7. 2-6) includes remote manipulator operations, 
deployment sequencing, Orbiter communications management to support EIUS telem- 
etry and commands and collision avoidance computations. The storage impact for 
these items is about 2.9K. 
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Table 6.7. 2-5. MSS Support Software (Overhead) Sizing 


FUNCTIONS 

FUNCTION/PHASE INITIALIZATION 

TABLES FOR FCOS INPUT/OUTPUT 
UTILIZATION 


INSTRUCTIONS 

400 


TOTALS 


400 
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FUNCTIONS 


INSTRUCTIONS 


RMS OPERATIONS 

ATTITUDE/COLLISION AVOIDANCE 
DEPLOYMENT SEQUENCE 
UMBILICAL MECHANISMS 
COMMUNICATIONS MANAGEMENT 


1,000 

250 

750 

500 

200 


TOTALS 


2,700 


TOTALS 


DATA 

(32 BIT WORDS) 

500 

938 

150 

250 

750 

938 

500 

625 

50 

156 


1,950 


2,907 





SPACECRAFT DEPLOYMENT OPERATIONS 

The primary responsibility of the IUS is to deliver a spacecraft to its 
desired location or orbital conditions. Since the IUS is a derivation of 
an existing vehicle with minimum spacecraft support capability and -since the 
Spacecraft community wishes to minimize the operational interfaces with an IUS, 
a minimum amount of lUS/Spacecraft operational interface during Spacecraft . 
deployment is anticipated. Some operation interface and interaction does 
exist, however, and this section will discuss the IUS operational support 
for the Spacecraft and the ground interactions to support the pre-deploy and 
post-deploy Spacecraft operations. 

7.1 SPACECRAFT PREDEPLOY OPERATIONS 

This section discusses the spacecraft predeploy operations which includes 
the activities from final IUS mainstage or trim burn until physical separation 
of the Spacecraft from the IUS. • :• 

7.1.1 IUS Support 

The major IUS functions to support the Spacecraft pre-deploy operations will 
be to provide an attitude control base for the Spacecraft while it is being 
activated and checked out, to provide activation and separation sequencing 
support, and in some cases, to provide the communication link interface with 
the ground. 

During the phases when the Spacecraft is being ferried from low earth orbit, 
to its final destination, the spacecraft may provide its own RF communications 
links with the ground. For some payloads, however, the Spacecraft RF communi- 
cation links may be covered or partially covered by shrouds, payloads adapters, 
appendages, etc., and for those cases, Spacecraft telemetry will be integrated 
with the IUS RF communications for relay to the ground. The command uplink 
for the Spacecraft will also be relayed through the IUS. During the Space- 
craft predeploy operations, the ground interface would be relayed through the 
IUS until the Spacecraft antennas were uncovered or until separation of the 
Spacecraft. In some cases, the ground would use the IUS command decoder, 
interface with the Spacecraft to execute selected functions initiated by 
Spacecraft ground control , > 

The IUS provides an attitude control base for the Spacecraft during the 
pre-deploy operations. The IUS will maintain attitude control for both the 
IUS and Spacecraft until they are separated. This allows the Spacecraft to 
be activated, its appendages extended, and the attitude control and RF ground 
interfaces to be verified prior to separation. If Spacecraft anomalies occur, 
the IUS can maintain the attitude base for a limited time until work-around 
corrective action can be taken by the ground. 

The IUS is expected to provide direct support for the Spacecraft, even- though 
these services will be minimized to the extent' possible. The two main IUS 
functions are Spacecraft activation sequencing and Spacecraft orientation and 
spin-up, if required. The activation sequencing may be initiated or performed 
by the ground, however, the IUS will provide sequencing capability, through 
the electrical sequence system from the IUS computer, for functions such as 
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shroud deployment, antenna deployment, solar array deployment, and power 
activation. If required, the IUS will provide the operation base for the 
orientation and spin-up of a Spacecraft prior to separation. 

The capability may eventually be provided for the IUS to monitor critical 
Spacecraft parameters and react to anomaly situations, but this is not 
required or particularly desired -by the Spacecraft community. Some design 
modifications would also be required for the baseline IUS to allow additional 
interface with the IUS computer, 

7.1.2 Ground Support 

Both the Spacecraft Operations Center (SCOC) and the IUS Operations Center 
(IUS/OC) will actively participate with each other as well as monitor and 
control vehicle operations during the pre-deploy operations. 

The IUS/OC will be- primarily responsible for monitoring the IUS status and 
operations to assure no operational or anomaly impacts which could endanger 
the Spacecraft. The emphasis will be on critical subsystem status and 
hazardous situations, such as over pressurization. There will be extensive 
interface between the SCOC and the IUS/OC during this phase for. status in- 
formation, for attitude and operations potential conflicts, and to assure the 
correct procedures are executed in the proper sequence. 

The SCOC will have the primary responsibility for Spacecraft activation and 
operational verification. It will use Spacecraft telemetry and selected 
event inputs from the IUS via the IUS/OC to determine if the Spacecraft is 
ready for separation and if all Spacecraft functions are operational. In the 
event of a malfunction, the SCOC will actively command and control the Space- 
craft to eliminate the problem. Any interaction requests for the IUS will be 
relayed through IUS/OC for their command inputs to the IUS and appropriate 
feedback to the SCOC . 

7.2 SPACECRAFT POST -DEPLOY OPERATIONS 

This section discusses the Spacecraft deployment operations from separation of 
the Spacecraft from the IUS until the IUS is a safe distance from the Spacecraft 
and can no longer' impact the Spacecraft or its mission. 

7.2.1 IUS Support 

After the Spacecraft separates from the IUS, the IUS can no longer interface 
with the Spacecraft or provide any additional support. The IUS has no pro- 
visions for docking, cannot provide an RF link with the Spacecraft, and has 
no onboard TV which might be used for a visual inspection of the Spacecraft. 
Therefore, the responsibility of the IUS is to assure a clean separation from 
the Spacecraft, to maneuver away from the Spacecraft without recontacting or 
contaminating the Spacecraft, and to maneuver to some orbit where it can no 
longer affect Spacecraft operations. 
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7.2.2 Ground Support 

After separation, the SCOC has the prime responsibility for the Spacecraft, 
while the IUS/OC has the responsibility for evasive maneuvers and disposal of 
the IUS (if expendable). The primary interaction between the ground centers 
is to avoid situations where recontact or contamination of the Spacecraft 
could occur and to identify any IUS problems (by the IUS/OC) which could 
jeopardize or potentially impact the Spacecraft mission. When the IUS is a 
safe distance from the Spacecraft, ground center interface is no longer 
required. 

The SCOC will monitor the Spacecraft status and perform any required activation, 
checkout or operational monitoring or commanding. The SCOC will also react 
to any potential IUS impacts on the Spacecraft if they occur. 
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FLIGHT OPERATIONS SUPPORT ANALYSIS 



During the IUS/Tug time frame, NASA's Spaceflight Tracking and Data Network 
(STDN) will consist of two subnets: the Tracking’ and Data Relay Satellite 

System (TDRSS) subnet and the STDN ground site subnet. The TDRSS will provide 
two Tracking and Data Relay Satellites (TDRS) plus a TDRSS ground terminal. 

The post-1979 ground site subnet will be- composed of six to eight sites from 
the STDN. Ground sites are currently planned at the following locations: 
Goldstone, Madrid, Orroral , Fairbanks, Merritt Island (launch only), Rosman, 
Bermuda (launch only), and Tananarive (launch only). 

The major functions of the STDN are to: (1) track spacecraft and relay 

launch and trajectory data in real-time from spacecraft to control centers; 

(2) relay commands from control centers to spacecraft; (3) relay telemetry and 
TV signals both in real-time and in store-and-forward modes from spacecraft 
to control center; (4) relay voice communications between control centers and 
spacecraft; and (5) augment recovery communications, as required. 

Although the present network provides sophisticated tracking and data acquisition 
support to earth-orbiting spacecraft, it does have such limitations as space- 
craft access time, geographic coverage, and information bandwidth. These 
limitations, in turn, impose design and operational constraints on the user 
spacecraft. To reduce these limitations, as well as to minimize the overall 
cost of tracking and data acquisition, NASA has been studying the use of a 
Tracking and Data Relay Satellite System (TDRSS) to augment the STDN. 

The TDRSS (see Figure 8. 0.0-1) consists of two geosynchronous satellites, 
approximately 130 degrees apart in longitude, which will relay tracking, 
telemetry, and command data between low earth -orbiting user spacecraft 
(<1200 Km), and a ground terminal located in the continental United States. 

This concept also provides for two spare satellites, one in orbit-, and- the other 
in configuration for a rapid launch. A "bent-pipe" concept is used in the^ 
design of the telecommunications service system : (i.e., all communication signals 
received at the Tracking and Data Relay Satellite (TDRS) are translated in 
frequency and retransmitted), making possible almost continuous reception of 
data in real time. 

'8.1 STDN/TDRSS DATA FLOW 

The data flow from the STDN and TDRSS is illustrated in Figure 8. 1.0-1. 

Several paths are available to the user, dependent on which subnet .of the STDN 
is being utilized. -If the user is transmitting -data to- either of the two TDRSS's, 
a direct flow is available to the White Sands ground station. The ground 
station will also function as a bent pipe repeater and process the data only -to 
the extent that it is acceptable to the NASOOM interface. NASGOM tin this 
instance can provide land line capabilities up to 1.3 Mbps. Domestic satellites 
are also being considered which will provide up to a 50 Mbps/transponder 
capability from the TDRSS ground station to the user. 

If the STDN subnet is used, several possibilities exist. Data acquired by the 
sites located within the continental United States will be processed to inter- 
face with NASCOM. Definition of the NASCOM capabilities for theshuttle era 
has not been presented; however, a single land line capability will be 
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available for 1.3 Mbps. NASCOM capability from the remote site is even more 
loosely defined. Presently, a 21.2 Kbps capability exists at the STDN 
stations. The Deep Space Network (DSN) and Fairbanks (ULA) have a wideband 
circuit to GSFC capable of 28.5 Kbps. Rosman has a 1.5 MHz circuit to GSFC. 
This may be increased by the use of satellite communications or other NASCOM 
enhancements. It is expected that data from the STDN will be -routed -to GSFC; 
GSFC in turn will act as a switching and distribution center to re-route the 
data to the users. 

8.1.1 STDN/TDRSS Telemetry Data Flow and Processing 

It is planned that both subnets will present the same interface to the STDN 
user and both can provide telemetry, command, and tracking to any user. The 
capabilities planned at the STDN subnet interface have not been defined at 
this time. 

8. 1.1.1 TDRS Telecommunications Links 

The concept of the TDRS telecommunications links is explained below as a basis 
for TM data flow and processing (reference Figure 8. 1.1-1). 

The telecommunications link from the -ground terminal to the TDRS to user is 
called the forward link, and the link from the user to TDRS to the ground is 
called the return link. The forward links carry user command data, tracking 
signals, and voice transmissions, and the return links carry user telemetry 
data, return tracking signals, and voice. Both the forward and return links 
consist of two segments: 



Figure 8. 1. 1-1. Two-Satellite TDRSS Concept 
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• Space-to-Space Link - This is defined as the link between 
the TDRS and the user spacecraft. 

« Space-to-Ground Link - This is defined as the link between 
the TDRS and the TDRSS ground terminal. 

Each TDRS contains the following antennas to support the space-to-space 
communication links and the space-to-ground communication links: 

• Space-to-Space Communication Links - 

(1) One 40-element, S-band antenna system: 10 elements are 

used to support the forward link; the remaining 30 elements are 
used as an array antenna to support the return (telemetry) link 
•of 20 users simultaneously. This antenna system is called the 
Multiple-access (MA) system; user spacecraft supported on this 
system are called MA users. 

(2) Two 3.8-meter parabolic antennas operating at S- and Ku-bands: 
Each antenna system is called a Single-access (SA) system because 
each antenna normally will support one user at a time. However, 
each antenna can support two users simultaneously (one at S-band 
and one at Ku-band) provided both users are within the beamwidth 
of the antenna. The user spacecraft supported on these antennas 
are called S-band Single-access (SSA) users or Ku-band Single- 
access (KSA) users. 

• Space-to-Ground Communication Links - One 1.8 meter, parabolic 
Ku-band antenna. 

8. 1.1. 2 TDRS Users 

The users of the TDRSS are classified by the type of service they require 
from the system. 

• Multiple Access User - The MA user is an S-band user serviced 

by the TDRS phased array. The maximum return link bit rate under 
most circumstances is 100 Kbps. 

• S-Band Single Access User - The SSA user is serviced by one of the 
3.8 meter parabolic antennas on the TDRS. The return link bit 
rates can vary from 1 Kbps to 6 Mbps. 

• Ku-Band Single Access User - The KSA user is serviced by one of 
the 3.8 meter parabolic antennas on the TDRS. The maximum band- 
width is 225 MHz, thereby providing a 150 Mbps biphase or a 300 
Mbps quadriphase bit rate on the return link. 
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8.1. 1.3 TDRS Telemetry Flow 


Two of the three user services provided by the TDRS, MA, and SSA are explained 
in further detail in the following paragraphs. The Single Access Ku-band 
system capability far exceeds IUS requirements at this time. 

Each TDRS will be designed to support a minimum of 20 MA users simultaneously. 
The multiple access system employs a 30-element S-band phased array antenna 
to minimize onboard complexity. Adaptive beam forming functions are performed 
at the ground station. The MA link performance for each user is a function 
of the number of MA users within view of the TDRS, their data rates, and 
power outputs. 

Each user may have a different data rate. The average user's raw real-time data 
rate is 11.5 Kbps plus overhead (approximately 10 percent) or approximately 
12.7 Kbps. To this, each user spacecraft may add 15 percent for the trans- 
mission of data stored onboard during the blind period, thereby yielding an 
average rate of 14.6 Kbps. The total data rate for 20 users plus overhead is, 
therefore, approximately 292 Kbps. From time to time, users in the system 
will change as new spacecraft are launched and old ones are discontinued. 

Data rates may increase up to 25 percent on the average for the projected 
system. The total bit rate from the S-band array may, therefore, be projected 
as high as 365 Kbps through the ground links. 

The TDRS SSA return link includes two 3.8 meter antenna steerable by ground 
command. Autotrack capability does not exist due to weight consideration. 

The SSA service provides a 10 MHz receive bandwidth and throughput capability 
of 1 Kbps to 6 Mbps. The 10 MHz bandwidth is sufficient to accommodate video; 
however, no provisions are made at this time to accommodate video data at the 
TDRS ground station. 

SSA and MA return link data is frequency translated onboard the TDRS for 
. transmission to the ground in the Ku-band frequency range. 

8. 1.1. 4 TDRS Ground Terminal 

The TDRS ground terminal provides three primary services: (1) forward user 

commands to the TDRS for transmission to user spacecraft, (2) receive user 
TM and provide the NASC0M interface for transmission to the user, and 
(3) receive Range and Range Rate data as an input to the GSFC orbit deter- 
- mini tat ion system. 

The ground terminal will be capable of receiving and handling downlink data 
from 20 MA users, 6 KSA users, and 6 SSA users simultaneously. However, for 
the SA systems only 4 KSA and 4 SSA data streams from the two operational 
spacecraft will normally be scheduled. The ground terminal will: 

a. Receive the return links from the two operational TDRSs. The 

receiving system is designed to provide a sufficient signal margin 
for reliable contact between the satellites and the ground terminal. 
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b. Demultiplex the received signals to recover user spacecraft data 
and ranging data. 

c. Generate the proper PN codes for extracting range information, 
and, in the case of the MA users, uniquely identifying each of 20 
user spacecraft. 

d. Demodulate the received user spacecraft telemetry in accordance - 
with the modulation technique used. 

e. Bit synchronize, and decode the user telemetry in such a manner to 
interface with NASCOM for transmission to the appropriate user 
control center and/or the data processing system at GSFC, or other 
non-GSFC locations. 

The content of user spacecraft telemetry will not be monitored or altered at 
the ground terminal. It will be routed via NASCOM to the appropriate user 
control and data processing facility. Presently, all data will be routed to 
the user as it is acquired by the TDRS ground station in a real time mode. 
On-site storage capability for store and forward is not being planned. 

Because users of the TDRSS are divided into primary categories, MA and SA 
users, the methods of ground data handling will be somewhat different. 

The MA user channels are recovered by demultiplexing the converted Ku-band 
return link from the TDRS. A signal to interference ratio can be established 
for each MA user by combining signals received from the various elements of 
the MA antenna array in the proper magnitude and phase. The SSAchannels are 
also recovered from the converted Ku-band signal. Beam forming is not 
necessary for SSA user signals. 

8.1.2 STDN/TDRSS Tracking Modes and Processing 

The TDRSS ground terminal is assigned to be furnished with a single tracking \ 
data processing system providing both high and low rate sample range and 
range rate (R&RR) data for all spacecraft tracked via TDRSS in a standard 
format. The estimated maximum data rate, including transmission overhead, is 
4.8 Kbps. This channel will be active almost continuously and at present is 
considered to be routed through to the GSFC orbit computation center, but also 
may be bridged to other locations. 

The user MA system must be capable of providing PN code coherence so that 
ranging computations can be performed on the ground. Because PN code modu- 
lation is used in both forward and return links, a PN code synchronization 
must be established before any functions can be performed. After synchro- 
nization, data can be transmitted in both directions. Ranging is accomplished 
by computing the transit time of the signal from TDRS to user to TDRS. 

The ranging subsystem accepts digital R&RR data from the RF system MA and SA 
demodulators and processes it for delivery to the Orbit Determination System 
(ODS) via the NASCOM interface. It also accepts TDRS R&RR data from the RF 
system bilateration correlator, or alternatively, from the S-band backup 
system TDRS demodulator. The ranging subsystem uses this data in two ways. 
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First, it processes the data for delivery to ODS via the NASCOM interface. 

Also, it performs some on-site calculations to provide ranging information 
to the attitude and stationkeeping processor. 

TDRSS tracking capability can be summarized in the following manner. User 
satellite position in near polar orbits can be determined to an uncertainty 
of 60 meters and accuracy is degraded as the user inclination approaches that 
of the TDRS . Tracking accuracy is dependent on the length of the data arcs 
and the number of supporting TDRSs (1 or 2). 

The TDRSS is expected to provide three types of user services. The first two 
services are defined for information; the third for its applicability to IUS . 

§ Routine Orbit Determination - Necessary only to establish orbits 
sufficient to predict future satellite position for acquisition 
by ground station and TDRSS and for network scheduling data. 

• Precision Orbit Determination Accuracy - Necessary for satellite 
systems to properly analyze and evaluate sensor data. Requirements 
today exist for 100 meters or less. Future requirements may be more 
stringent. 

» Real Time Orbit Determination - Accuracy necessary for those 
satellite subsystems which must execute maneuvers and guarantee 
spacecraft and/or shuttle crew safety. Accuracy requirements' will 
vary dependent on mission; however, short data arcs taken in a 
limited amount of time will be the rule of the day. 

8.1.3 STDN/TDRSS Command Flow and Processing 

The TDRSS forward link (command) is characteristically described by the type 
of user - single access or multiple access. 

The MA command channel of the TDRS radiates via the 10 element transmit array. 
The MA uplink is a single frequency time division system with the capability 
to command only one MA user at a time. The user will interface with the TDRS 
ground- terminal . The ground terminal will provide the proper scheduling and 
support element selection (antennas, transmitters, carrier modulation, etc.,) 
to the user. To be consistent with the throughput philosophy of the TDRSS 
user, commands will be generated, transmitted, executed, and verified by the 
applicable user control center. The forward link will support MA user require- 
ments up to 10 Kbps. Uplink commands from the user control center will be in 
a real time mode only, command storage and load capability does not exist at 
the ground station. 

The SSA forward link user can operate in a narrowband or wideband (under 
consideration) mode. Uplink data rates are variable from 100 bps to 500 Kbps. 
Operational considerations for the SSA forward link are similar to the MA 
characteristics of the last paragraphs . 

8.2 NETWORK CHARACTERISTICS AND CONFIGURATION 

The eight station STDN subnet and single TDRS ground station comprise the STDN. 
As part of the STDN, operational control of the TDRSS ground terminal will be 
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exercised by the Network Operations Control Center (NOCC). The NOCC will send 
the ground terminal a weekly user support schedule via NASCOM. The schedule 
will specify the support times, user spacecraft frequencies, and Acquisition of 
Signal/Loss of Signal (AOS/LOS) times. This basic support schedule will be 
used to generate a detailed TDRSS utilization schedule, i.e., an activity plan. 
Other inputs to the activity plan will- include: (a) user and TDRS data; (b) 

ground terminal status; and (c) other required TDRS commands. The same types 
of utilization schedules are expected to be provided to the eight STDN stations. 

The STDN is configured to provide two types of support: (1) launch support 

and, (2) high altitude satellite support. The launch support stations will 
be configured and scheduled for that expressed purpose. Even though the 
support configuration has not been finalized, it is expected that the launch 
stations will not have the full capability of the other STDN stations. 

Fairbanks will provide support to the high inclination orbits, while Orroral , 
Madrid and Goldstone will be significant to those missions requiring support 
characteristics of the Deep Space Network (DSN). 

The STDN and TDRSS significantly differ in their design and support concepts. 

It follows then that their operational constraints are different. 

8.2.1 STDN Network Operational Constraints 

The STDN will function primarily as a high altitude mission support network, 
and operational support constraints will be described as they relate to these 
objectives . 

Keyhole Considerations - The STDN will probably utilize one or more of the 
three basic S-band antenna systems; the 9 meter (30 * ), 12 meter (40‘), or 
26 meter (85 1 ) parabolic dish. These antenna systems utilize an X-Y mount. 

The X-Y mount application is used because zenith coverage is accomplished 
which is not possible with the convential Az-EL mount. The X-Y mount is 
capable of tracking through zenith but has a gimbal restriction keyhole near 
the horizon. The restriction is generally oriented north to south on the 9 
meter systems and east to west on the 26 meter systems (Figure 8. 2. 1-1). 

Signal loss is most significant during low altitude missions and becomes less 
significant as altitude increases. In the past, losses up to a 15 degree 
antenna elevation angle has occurred. Additional time may be required during 
a pass to re-acquire phase lock once the vehicle has passed through the keyhole. 

Terrain Features - In addition to the keyhole effect, S-band antenna system 
performance will be degraded by terrain features, i.e., mountainous terrain. 
Obviously, this is related to station location. 

Attitude Considerations - The onboard S-band phased array antenna will have a 
limited beamwidth. To - maintain satisfactory communications with the ground 
stations at acceptable gains and bit error rates, the attitude and pointing of 
the vehicle will be restricted. 

Handover Considerations - At altitudes above 6500 KM, the STDN should be able 
to provide continuous coverage of the vehicle. During this time period signal 
losses during handover should be minimal, since downlink lock can be established 
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Figure 8.2. 1-1. S-Band Antenna Keyholes 

by more -than one station. Handover becomes primarily procedural. If handover 
is complicated by'vehicle attitude constraints, ground terrain features, or the 
keyhole effect, then the signal loss may be more significant. 

STDN Ground Station Configuration - The S*TDN will be configured to primarily 
provide support to high altitude missions. Three stations, MILA, BDA, and 
TAN are configured’ for launch support only, and manning levelsfor these 
stations will be based on a single shift operation'. Four to five stations 
remain for orbital support. Fairbanks (ULA) will not provide. meaningful . 
low earth orbit, low- incl i nation support. Hence, the STDN is reduced- primarily 
to a four station network which is not capable of or designed for significant 
low altitude support. 

8.2.2 TDRSS Network Operational Constaints 

The TDRSS will function as' the low altitude mission support subnet, and its 
primary operational constraints are as follows: 

Handover Considerations - Assuming the vehicle has only one S-band antenna, 
three types of handovers must be considered: (1) vehicle to TDRS-E or TDRS-W, 

(2) TDRSS ground antenna switching, and. (3;) possible handover to. and from- the 
STDN. 
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Positional location of the vehicle S-band antenna will be s'ignficant because of 

(1) the need to slew the onboard antenna from one TDRS to -another, and the 
associated antenna slew times, and (2) the possible need for vehicle attitude 
changes to ensure communications. 

Of less significance will be the switching of the data source from one TDRS 
ground antenna to another as an input to the ground station data handling 
system. 

Handovers from one subnet to another subnet may result in signal losses; again 
dependent on the geometry involved relative to the vehicle, TDRS'and STDN. 

The following paragraphs will further explain the possible problems: 

TDRS Earth Occultation - The TDRS consists of two active geosynchronous 
satellites 130 degrees apart in longitude on station over the equator. The 
two active satellites do not provide full orbital coverage of the user vehicle 
due to earth occultation. Communications interruptions occur in what is 
termed the "zone of exclusion", with its cause and location illustrated in 
Figure 8. 2. 2-1. The zone of exclusion represents the lower altitude coverage 
limits for the TDRSS users, which is less than 1200 kilometers. The amount 
of coverage provided to a user spacecraft is a function of the user' altitudes 
and inclinations. User at low altitudes and inclinations will pass through 

the zone of exclusion on each orbit and receive the least coverage. However, 
users at higher altitudes and inclinations will pass through the zone of 
exclusion only periodically, e.g., a user at 1000 kilometers altitude and 99 
degrees inclination will pass through the zone of exclusion once per day or 
less. 

IUS Antenna Occultation Considerations - Vehicle antenna masking could be caused 
by the vehicle structure occulting the S-band antenna and the TDRS. This 
situation may occur if the space vehicle is held in an attitude with at least 
two axis fixed over an extended period of "time. 

User Coverage Constraints - The user can be provided with 100 percent coverage 
at altitudes greater -than 1200 KM. Twelve hundred kilometers represent the 
lower coverage limits of the TDRSS. The upper coverage limits for the single 
and multiple access systems are 12,000 KM and 2000 KM, respectively. A summary 
of the TDRSS orbital coverage follows: 

• Multiple-access 

(1) Minimum coverage at 200 kilometers. 

(2) 100 percent coverage between 1200 and 200 kilometers. 

(3) Coverage decreases towards zero for synchronous altitudes. 

• Single-access 

(1) Minimum coverage at 200 kilometers. 

(2) 100 percent coverage between 1200 and 12,000 kilometers. 

(3) Coverage decreases towards zero at synchronous altitudes. 
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8 .3 EIUS MISSIONS COMMUNICATION ANALYSIS 

The IUS vehicle data package used for this study is' compatible with STDN, 
and does not presently have the capability to interface with TDRS after 
separation from the Orbiter; however, NASA requirements do state that the IUS 
will be compatible with TDRS. Therefore, the study has assumed this capability 
for the following communications- analysis. Three representative EIUS missions 
were baselined for a network support study. Orbital trajectories were calcu- 
lated for interplanetary, sun synchronous, and geosynchronous missions, and 
line of sight geometric support by the STDN and TDRSS was assessed. In the 
initial assessment, all STDN sites were included, in order to provide a con- 
fidence that useful stations were not prematurely disregarded. Table 8. 3. 0-1 
illustrates possible mission support by percentage of mission time. Generalized 
ground support requirements for each phase of the IUS mission were: 

• Launch and Orbiter-Attached Operations (TDRS/STDI'O 

TM - 16 or 64 Kbps (Digital) 

CMD - 2 Kbps (Digital) 

Tracking - No Requirement 

• Post^-Deploy and Coast 

TM - 16 or 64 Kbps (Digital) 

CMD - 2 Kbps (Digital) 

Tracking - STDN for IUS « 


• EIUS Burns 

TM - 16 or 64 Kbps (Digital) 

CMD - 2 Kbps, .(Digital) 

Tracking - STDN for IUS 

• Payload Deployment (STDN) 

TM - 16 or 64 Kbps (Digital.) 

CMD - 2 Kbps (Digital) 

Tracking - STDN for IUS 

8.3.1 Sun Synchronous Mission Coverage 

The syn synchronous mission was analyzed for 0.50 days in length. The ascent 
burn delivers the vehicle 'to an altitude of 920 nautical miles where a cir-. 
culariza'tion burn places the vehicle into a circular orbit. . Spacecraft delivery 
and an orbit change burn -completes the EIUS mission. The mission .coverage 
indicated is from TDRS-E : , TDRS-W and the three station ground network composed 
of Goldstone., Orroral and Madrid. 

Figure 8. 3. 1-1 is a timeline of IUS mission events and .composite AOS/LOS of 
the TDRSs and STDN stations. AOS/LOS and mission events are also shown in 
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Figure 8.3. 1-1. El US Sun Synchronous Mission Timeline (TDRS/STDN) 

perspective on the mission trajectory traces in Figures 8. 3. 1-2 and 8. 3. 1-3. 
Only pertinent orbits are shown to maintain simplicity and ease of under- 
standing. The following conclusions are based on the known support periods, 
support station capabilities, and onboard system output rates. 

• The STDN does not provide any coverage during two critical 
mission time periods; the ascent burn and payload deployment. 

The STDN can supDort the circularization burn. 

• The TDRS can provide support for all burn periods and payload 
deployment. 

• IUS predeploy checkout and deployment will reauire the Orbiter/ 

TDRS interface for support. 

8 .3.2 Geosynchronous Delivery Mission Coverage 

The geosynchronous delivery mission was analyzed for a mission time of 1.66 
days. The ascent burn delivers the vehicle to an altitude of 19,323 nautical 
miles where a circularization burn places the vehicle in a stationary geo- 
synchronous position at -71° longitude. Payload deployment and an orbit 
change burn completes the EIUS mission. The mission coverage indicated is 
from TDRS-E, TDRS-W and the three station ground network composed of Goldstone, 
Madrid, and Orroral . As with the sun synchronous mission, MIL, ROS, and ULA 
provided minimum additional coverage. 

Figure 8. 3. 2-1 is a timeline of the geosynchronous delivery mission and 
summarizes the orbital support of both subnets depicted in Figures 8. 3. 2-2 
and 8. 3. 2-3. The following conclusions can be drawn from the timelines and 
the known network capabilities discussed previously in this section. 
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Figure 8.3. 1-2. EIUS Sun Synchronous ■ TDRS Only Case 


8-17 


NASA SUN SYNC MISSION 

AREAS OF NO GROUND STATION COVERAGE 

WE E W 



Figure 8.3. 1-3. EIUS Sun Synchronous - STDN Only Case 
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Figure 8. 3.2-1. EIUS Geosynchronous Delivery Mission Timeline (TDRS/STDN) 
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Figure 8.3.2-2. EIUS Geosynchronous - TORS Only Case 
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Figure 8.3.2-3. EIUS Geosynchronous ■ STDN Only Case 


• The STDN subnet can provide support to all major IUS 
burn periods. 

• The STDN will only provide limited support during IUS predeploy 
checkout and deploy from the Orbiter. Checkout support will be 
enhanced by IUS utilization of the Orbiter/TDRS interface. The 
Orbiter SSA or KSA interface will meet all IUS requirements. 

• The IUS Geosynchronous Mission does not directly require any 
capabilities offered by the TDRS except for deployment and 
on-orbit checkout operations. 

8.3.3 Interplanetary Mission Coverage 

The interplanetary mission analyzed was .66 days in length. The ascent burn 
delivers the kick stage/payload to an altitude of 737 nautical miles at 22° 
latitude and 155° longitude where separation occurs. The hyperbolic burn sends 
the IUS into a high elliptical orbit with an apogee of approximately 30,000 
nautical miles. The mission coverage indicated is from TDRS-E, TDRS-W and the 
three station ground network composed of Goldstone, Orroral , and Madrid. 

Figure 8. 3. 3-1 is a timeline of the interplanetary mission and summarizes 
the orbital support provided by the STDN and TDRS subnets. Individual subnet 
support is projected on Figure 8. 3. 3-2 and Figure 8. 3. 3-3. The following 
conclusions can be drawn from the timelines, known network capabilities, and 
the onboard systems capabilities. 

• The ascent burn is not supported by the STDN; however, the STDN 
can support the IUS post burn period through the hyperbolic burn 
and post hyperbolic burn periods. 

• The STDN can provide partial support to payload deployment. The 
TDRS can provide total coverage of payload deployment, however, the 
SSA user service would be required. 

• The addition of the capability of the IUS to directly interface with 
the TDRS would not be of benefit during the ascent burn. The burn 
occurs in the TDRS zone of exclusion for the case analyzed. 

• TDRS support will be required to the Orbiter for IUS checkout and 
deployment during low earth orbit. 

8.3.4 Summary of Communications Support 

In most instances, the STDN does not have the coverage necessary to support IUS 
checkout and deployment from the Orbiter. However, by IUS utilization of the 
Orbiter/TDRS interface, the necessary support will be provided without any 
modifications to the present IUS TM concepts. 

There are several cases where an IUS/TDRS interface capability will provide 
ground interface capability during periods when STDN support is not possible 
due to orbital geometry such as: 
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• Sun Synchronous Mission - Ascent burn and payload deployment. 

« Interplanetary Mission - The payload deployment and orbit 
change burn. 

Payload deployment on the interplanetary mission can be supported by the 
pointable S-band antenna and single access system. The IUS would exclude 
other MA users due to bandwidth considerations during the 64 Kbps periods. 

It is also recommended that the ground support and RF requirements be written 
to the next level of detail. This will accomplish two things; (1) impact the 
requirements against the onboard systems design, and (2) provide a baseline 
for a more indepth support network analysis. Support requirements should also 
be prioritized to gauge their impact; mandatory, highly desirable, desirable, 
and etc. 

The study provided network coverage times based on simp! istic, earth-IUS-STDN 
geometrical considerations only. Further studies should consider other geometric 
variables as mentioned in Section 8.2.1. 

• Keyholes 

• Terrain 

• Handovers 

• Vehicle Attitudes 

• STDN capabilities (must be defined first) 

• Vehicle antenna occupations 

8.3.5 Representative Network Loading for IUS 

The network loading created on the STDN/TDRS was determined based on several 
assumpti ons : 

• If the ground station was in line of site of the vehicle it 
supported the mission. 

• The IUS mission model presented in the Baseline Space Tug Flight 
Operation Document is representative of the actual missions flown. 

• The Sun Synchronous, Interplanetary, and Geosynchronous missions 
are representative of these missions. 

The typical mission model presented in the Baseline Space Tug Flight Operations 
document gave total of thirty one missions (deploy and/or retrieve) to be flown 
in 1984 and was considered to be representative for IUS missions. This total 
was made up of three categories of missions and is representated in Figure 
8. 3. 5-1. 

• Geosynchronous - 14 missions 

• Earth orbital - 12 missions 

• Earth escape - 5 missions 
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Figure 8.3.5-1. Network Loading for 1984 Missions (Typical for IUS) 

The three missions analyzed to obtain network loading data were assumed to 
provide average loading data for all other missions within their respective 
category. The missions analyzed were: 

• Geosynchronous (GS)/geosynchronous 

• • Sun synchronous (SS)/earth orbital 

• Interplanetary (IP)/earth escape 

The resulting average yearly loadings per station were a total of the hours 
required per station for support of the three missions analyzed. Roseman 
(ROS) and Merritt Island (MIL) had nearly duplicate coverage, while Alaska 
(ULA) provided minimum coverage. The minimum station network configuration that 
can provide economical coverage for the three different types of missions 
consist of Madrid (MAD), Orroral (ORR), Goldstone (GDS), TDRS-East, and TDRS- 
West. Additional analysis of the EIUS missions would be required to identify 
the optimum network configuration for IUS. 

8.4 OPERATING MODES OF MISSION CONTROL 

The Space Transportation System is a vast integrated operation within which 
is embedded a facility for the real-time control of the EIUS operations. 

Figure 8.4. 0-1 illustrates 'the five fundamental elements which must act 
together in order to effect the maximum efficiency of operations and their 
associated interfaces. 
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Each of the designated facilities has its own particular requirements. The 
Spacecraft Operations Center (SCOC) is responsible for the monitoring, command- 
ing and controlling of the Spacecraft ephemeris. The Spacecraft Operations 
Center is also responsible for the control, processing and analyzing of the 
scientific data derived from the experiments carried by the Spacecraft. The 
type of data coming into the- Spacecraft Operations Center relates to the 
trajectory, a limited amount of systems performance data and a large quantity- 
of scientific data. The outgoing information from the Spacecraft Operations 
Center consists fundamentally of commands to the Spacecraft and voice coordination 
with other centers within the operational complex. 

The Space Shuttle Operations Center (SOC) will be responsible for the monitoring, 
command and control of the Space Shuttle Orbiter vehicle and the attached 
payloads, with primary emphasis being .placed -upon crew safety operational 
requirements. The information supplied to the Shuttle Operations Center consists 
of trajectory measurement data, some system performance information and 
scientific data from those experiments which are carried onboard the Shuttle. 
During early phases of the flight, the Shuttle Orbiter trajectory will be 
utilized to provide initial phasing for the EIUS trajectory, therefore, it is 
required that this trajectory information be provided to the EIUS Operations 
Center. 

The EIUS is designed to operate a Level B autonomy, which requires a high 
level of ground involvement. The EIUS Operation's Center operation is equivalent 
to the combined control of the S4B/ Instrument Unit in the unmanned configuration. 
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Figure 8.4.0-1. Space Transportation Control Center Interfaces 
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Since there are no astronauts to assist in the control of the vehicle, complete 
system information and analytical capability must be maintained on the ground 
or integrated into the onboard data management system. 

The network, consisting of the TDRS and the STDN for NASA missions, is charged 
with the responsibility of routing data to the appropriate control center in 
usable format. At some point the downlink data stream must be split apart and 
segregated into scientific data routed to the Spacecraft Operations Center, 
scientific and system data is routed to the Shuttle Orbiter Control Center 
and detailed systems data routed to the EIUS Control Center. The network must 
also provide tracking information to all three centers. 

8.4.1 Prelaunch Operations 

The prelaunch operations element interfaces are illustrated in Figure 8.4. 0-1 
and are discussed in the following sections. 

8. 4. 1.1 IUS Operations Center/Launch Site Interface 

The IUS operations control center maintains a prelaunch interface with the 
Launch site. In the prelaunch period, the IUS operations center will monitor 
prelaunch systems testing from an informational and backup standpoint. In - 
some tests, such as command checkout and target loads, the IUS Operations 
Control Center will provide an active role. The EIUS Control Center will not 
act in other than an advisory capacity to the launch operations center during 
most prelaunch testing. There is not post-launch interface with the launch 
site. 

The primary purpose of the launch site is preparation of the Spacecraft, IUS 
and Orbiter for launch operations. The interface with the IUS Operations Center 
can include any and all aspects of systems readiness, verification and 
preparation. The launch operations center will acquire, process, and analyze 
prelaunch data, and will provide the data either in real-time or near-real- 
time to the IUS Operations Control Center for analysis and concurrence. The 
countdown will be conducted at the launch site. 

8. 4. 1.2 IUS Operations Center/Shuttle Operations Center Prelaunch Interface 

The IUS Operations Center will interface with the Shuttle Control Center (SOC) 
during prelaunch for systems coordination purposes. The IUS requires all systems 
be monitored at the Control Center. There will be minimum dependence upon the 
Orbiter crew for any functions other than caution and warning monitoring. No 
prelaunch tests or system performance will be conducted by the Orbiter crew. 

Since the Orbiter crew will be in contact only with the SOC, any system functions 
of the IUS which change the status of any parameter displayed to the astronauts 
must be pre-coordinated through the SOC air-to-ground voice loop. There will be 
no direct voice contact between the IUS Operations Center and the Orbiter crew. 

The Shuttle Orbiter Control Center functions are devoted primarily to the 
control and monitoring of the Orbiter vehicle, with major effort being devoted 
to the Spacecraft and EIUS Caution and Warning function. Primary responsibilities 
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will center around crew safety involvement of the Space Transportation System. 
Primarily the Shuttle Orbiter Control Center will monitor the - Orbiter launch, 
provide voice communication with the crew and real-time data analysis during 
the boost phases. 

Following insertion into low earth orbit, the Space Shuttle Control Center 
will be responsible for managing the Orbiter trajectory, not only during the time 
period for shaping the EIUS phasing, but also during the subsequent phases of 
the mission during which Shuttle onboard particular experiments are being 
conducted. 

During all phases, the Orbiter system will be monitored for proper performance 
and voice communication established with the crew for the purpose of coordinating 
system condition information. The Shuttle Orbiter Control Center will also 
be deeply involved in alternate missions and contingency operations and support, 
including recovery, landing and rescue operations. 

8. 4. 1.3 I US Operations Center/Spacecraft Operations Center Prelaunch Interface. 

During prelaunch operations, the focus of activity is on the launch site, Orbiter 
and Orbiter Control Center. The IUS Operations Center and Spacecraft Operations 
Center (SCOC) perform backup and monitoring functions only. The Spacecraft 
Operations Center is primarily concerned with Spacecraft readiness, while the 
IUS Operations Center performs the same assessment. There are some potential 
spacecraft/IUS physical interfaces which acquire operations coordination in 
order to ascertain the systems operability. 

8.4. 1.4 IUS Operations Center/Network Prelaunch Interface 

The Network will acquire real-time telemetry and provide a command interface 
during prelaunch operations through a ground site located near the Launch 
Operations. The IUS Control Center will generate commands through the net- 
work to the IUS, and will monitor feedback from the IUS over the RF links. 

A1 1 operational interfaces between the IUS Control Center and Network will be 
verified during the prelaunch phase. Any anamoly will be cause to hold the 
launch count, since the network is essential to the conduct of post launch IUS 
operations. 

8.4.2 Predeploy Operations 

The predeploy operations interfaces between the operations elements are 
illustrated in Figure 8. 4. 0-1. This section briefly discusses the element 
interfaces and interactions during the predeploy phase. 

8. 4. 2.1 IUS Operations Center/Shuttle Operations Center Predeployment Interface 

The IUS Operations Center must maintain knowledge of the Space Shuttle Trajectory 
in the predeployment period, since the Orbiter trajectory is integral to the 
IUS mission trajectory plan. A low-speed state vector interface will be 
communicated from the Orbiter Control Center to the IUS Control Center during 
the predeployment period. 
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The IUS Operations, Center monitors all downlink data from, the IUS, and acts 
as backup analyst to support Orbiter-derived IUS concerns. Any communication 
with the Orbiter crew will be through the IUS Operations Center/Shuttle Orbiter 
Operations Center coordination loop. There will be no direct astronaut/IUS 
Operations Center communication. 

The Shuttle Orbiter Control Center functions are devoted primarily to the 
control and monitoring of the Orbiter vehicle, with major effort being devoted 
to the Spacecraft and EIUS Caution and Warning functions. Primarily the 
Shuttle Orbiter Control Center will monitor the Orbiter launch, provide voice 
communication with the crew and real-time data anaysis during the boost phases. 
Following insertion into low earth orbit, the Space Shuttle Control Center 
will be responsible for managing the Orbiter trajectory, not only during the 
time period for shaping the EIUS phasing, but also during the subsequent phases 
of the mission during which Shuttle onboard particular experiments are being 
conducted. During all phases, the Orbiter system will be monitored for proper 
performance and voice communication established with the crew for the purpose 
of coordinating system condition information. The Shuttle Orbiter Control 
Center will be deeply involved in alterate missions and contingency opera- 
tions and support, including recovery, landing and rescue operations. Primary 
responsibilities will center around crew safety involvements of the Space 
Transportation System. 

8. 4. 2. 2 IUS Operations Center/Spacecraft Operations Center Predepl'oyment 
Interface 

The IUS Operations Center and Spacecraft Operations Center interface during 
the predeployment phase. At this time, the IUS and the spacecraft are still 
secured within the Shuttle Orbiter cargo bay. There is no significant dif- 
ference in the operations in the prelaunch and predeployment periods as. regards 
the interface between the Spacecraft Operations Center and the IUS Operations 
Center. Operations coordination is required in order to advise the Centers ■ 
of onboard events which may change the status of their displays. 

8. 4. 2. 3 IUS Operations Center/Network Predeployment Interface 

The ground network provides support to all control center operations. The 
network acquires, processes and distributes data to the control centers. The 
primary functions of network data support are to schedule the network facility 
to meet the particular program, experiment, and vehicle support requirement. 

The network interface with the IUS has been verified in the prelaunch period. 
The interface between the network and the IUS Operations Center in the pre- 
deployment period provides the information to the IUS Control Center which 
was provided by the launch site in the prelaunch period. The primary function 
is to monitor system data and provide backup information through the Spacecraft 
Operations Center to the astronauts in the event of operational coordination 
requirements. 

8.4.3 Post-Deploy Operations 

The Orbiter crew will monitor and control the IUS systems performance during 
all cargo bay manipulator arm and near-in operations where there is a crew 
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safety involvement. After deployment, however, the operational interface 
become somewhat more complex. The post-deploy interfaces are shown in 
Figure 8. 4. 0-1. 

8.4.3. 1 IDS Operations Center/Shuttle Operations Center Post-Deploy Interface 

During post-deploy operations, data is provided to the Shuttle Orbiter Control 
Center, the IUS Operations Center and the Orbiter crew relative to the IUS 
systems condition. Any command action undertaken by the IUS Operations Center 
must be pre-coordinated through the Shuttle Operations Center to the Orbiter 
crew so that any change in system status indications will not be unexpected. 

The immediate post-deploy time frame is critical to mission success and will 
require close team work and coordination activities. Trajectory measurement 
information will be supplied to the IUS Operations Center simultaneously with 
the supply of trajectory measurement informationto, the Shuttle Operations 
Center. During the immediate post-deploy period, there exists an opportunity 
to compare IUS and Shuttle state vector information. 

8. 4. 3. 2 IUS Operations Center/Spacecraft Operations Center Post-Deployment 
Interface 

During the post-deployment phase, the spacecraft is still a passenger aboard 
the IUS vehicle. System data from the spacecraft will be provided to the 
network through the IUS downlink and, in the network, will be distributed 
to the Spacecraft Operations Center, where it will be assessed and analyzed. 
There exists the potential that a command uplink will be required to use 
corrective actions to the spacecraft systems. No command action may be taken 
to the spacecraft without pre-coordination with the IUS Operations Center. 

The IUS Operations Center will be monitoring IUS parameters and a selected 
set of spacecraft parameters. The IUS trajectory measurement and system data 
will be processed through the network through the IUS Control Center. 

8. 4. 3. 3 IUS Operations Center/Network Post-Deploy Interface 

In the post-deploy operations, the ground network will receive and process 
systems data and trajectory measurement data for the IUS Operations Center, 
and will provide a command uplink capability between the IUS Operations 
Center and the IUS vehicle. Command two-way lock is required during all mission 
phases other than while the IUS is in the Orbiter cargo bay. Many of the IUS 
functions require a command initiation or a command backup capability. Ground 
tracking, range and range-rate data will be acquired by the network and processe< 
to the IUS Control Center at all times following separation from the Shuttle 
Orbiter. Remote-site data processors will perform special calculations to 
support consumables analysis and delta velocity computations as established by 
the network data handling requirements. The network receiving site will' record 
and process data for retransmission, preserving the historical in the process. 
The network will provide real-time data routing and distribution to all user 
agencies. The network will also provide special processing support, such as 
the re-packing of data, logical operations, and special processing as required 
by the particular program and established in pre-mission period. The network 
will also provide a catalog of, and maintain, historical data archieves for all 
programs . 
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8.4.4 Spacecraft Deploy Operations 

Figure 8. 4. 0-1 illustrates the spacecraft deploy operations coordination loops. 

The IUS mission will have carried the spacecraft to the planned deployment 
location. Since there, exists no capability for communicating- with the space- 
craft after separation, the only IUS function is to provider stable attitude 
and establish predeployment conditions for the spacecraft prior to totally 
losing contact with it. 

The spacecraft systems will be activated by the IUS either automatically or 
through ground command prior to separation. Upon activation, the spacecraft 
will begin communicating trajectory, system data, and scientific data to the 
Spacecraft Operations Center. The spacecraft will also be prepared to’ accept 
command uplink data through the network, if that capability has not existed 
previously during its role as passenger on the IUS. The primary coordination 
problem is in ascertaining that the correct predeployment conditions have been 
reached by the IUS. This requires operational coordinatioh between the Spacecraft 
Operations Center and the IUS Operations Center, particularly in the comparison 
of ephemeris achieved versus ephemeris desired. 

Once separated, the IUS will phase away from the deployed spacecraft. Following 
a .successful phasing maneuver, the IUS will be retargeted to insure no inter- 
ference with spacecraft operations. 

8.5 CONSIDERATIONS FOR "NEW BUILD" CONTROL CENTER DESIGN 

The objective of this task was to identify development concerns incurred during 
the establishment of NASA/DoD Mission Control Centers. All- elements of the 
Mission Control Center development activity were addressed, with existing 
approaches identified, so that developmental problems could be avoided in 
defining the IUS/Tug operations concepts, functions, and plans. Several 
center/programs were assessed for requirements; such as, staffing, computer 
capability, software, hardware and facility. Those centers included are 
JPL-Deep Space, AMES-Pioneer, JSC-Apollo and Gemini, GSFC-Unmanned Satellites 
and the Air Force Satellite Test Center (AFSTC) . 

8.5.1 NASA/ DSC Development Concerns 

8. 5. 1.1 Operational Philosophy 

Prior to discussing any development activities, it is benefical to understand 
the operational objectives and environment of each center. JSC is currently 
configured (as in the past) to support missions of relatively short durations 
on an infrequent launch basis. 

The JSC Mission Control Center and associated tracking stations are set up 
as a system rather than project oriented; therefore, it is reconfigured from 
project to project. Occasionally part of the system ( i . e . , control console, 
displays, memory systems) are updated or upgraded, however, an attempt is • 
made to normally have the resources required to support a project, rather than 
modify the MCC into a project specific configuration. When equipments 
acquired to support a project, a growth factor is added whenever possible 
to accommodate future requirements. 
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8. 5. 1.2 Systems Configurations 

The basic MCC consists of the Real Time Computer Complex (RTCC) composed. of 
five IBM S360/75's on parallel input and output busses, console. areas for 
flight controllers, network controllers (STDN) , and instrumentation controllers. 
Real time processing is a major MCC effort. The second largest effort is 
system validation and training. The RTCC is used 99 percent of the time in 
these roles, with one percent of the total utilization spent on actual flight 
support. The third largest effort is the off-line data processing by other 
computers, Univac 1108; however, the RTCC computers provide the interface for 
this data as input-to JSC from the remote sites. 

To alleviate scheduling problems, NASA writes a development plan for each 
major MCC change. This plan assures a close coordination of the contractors 
and government and is closely followed and reviewed to identify problems at 
an early stage. A need was developed for extensive software configuration 
planning and development control. 

Some development concerns were created outside the realm of the MCC; however, 
a direct relationship exists from data acquisition by the onboard sensor to 
data processing at the MCC. This resulted in a major problem in ground tele- 
metry processing caused by the non-uniformity of onboard data communication 
systems. An indexing counter in the main frame would simplify the ground 
decommutation process in many cases, however, it was not provided because it 
is not required for onboard commutation. NASA should coordinate the commutation 
and decommutation developments to reduce the total cost of data processing. 

8.5. 1.3 Roles and Responsibilities 

There are about 160 NASA people and 900 contractor personnel active in the JSC 
MCC operation. IBM is the software contractor and integrator for the RTCC, 
and Phil co Houston Operation ( PHO ) is the hardware integrator and system 
Maintenance and Operations contractor for all except the RTCC. Various manu- 
facturers provide contracted maintenance on their data processing equipment. 

NASA retains the system integrator and system engineer roles, and additionally 
supplies facilities and precision measurements and equipment laboratories. 

8. 5. 1.4 Identified Design/Development Concerns 

Further evidence of the end to end impact of processing on the data flow 
system occurred during the Gemini mission. It was found that the command 
uplink had been designed to give a very low error rate (redundant commands, 
encoding, high gain antennas, etc.) while command verification was based 
on a two watt transmitter in a high error rate link. The result was that 
errors in the downlink caused the MCC to transmit many commands unnecessarily. 

JSC committed early in the development stage to reconfigure the RTCC by 
software changes when signal sources varied between missions. In some 
instances, where there was a minimum time between launch centers and signi- 
ficant requirement for support, simulation, or training, software changes were 
not possible and wiring changes proved more feasible. Software freezes caused 
subsequent reconfigurations to be made by rewiring the data inputs to the 
RTCC's. Wiring changes were selected because of simpler validation and less 
man hours. 
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The MCC/User interface needs attention to assure that anomalies in the 
experiment are understood 'by the personnel creating the telemetry reduction 
software. In essence, the software was designed to operate with less than 
perfect data. Rather than requiring simple software changes, such as change 
coefficients, software required more extensive programming efforts, revalid- 
ation, etc. If software were more flexible, the software quality assurance 
effort could then identify immediate products in the processing needed to 
assure that discrete steps are properly implemented. In many other cases, 
the user stated his requirements without considering the processing load 
involved (color imagery vs. black and white), which resulted in a reduced 
utilization of the MCC resources. 

8.5.2 NASA/ JPL Development Concerns 
8.5.2. 1' Operational Philosophy 

The JPL Mission Command and Control Center (MCCC) is viewed as a support 
service to the various deep probe programs offices. "Institutional Software" 
at JPL performs the actual communications functions with the Deep Space 
Network (DSN) sites in Spain, Australia and Goldstone, California. Other 
"institutional" routines for orbit planning, video and telemetry reduction, 
and command generation, are available for use by the probe program. Mariner 
(JPL) is controlled in the JPL Mission Test Control Facility (MTCF, Univac 
1218, 1230 and 116 computers). Pioneer is controlled at NASA Ames (Xerox 
Sigma 5s and PDP 11s). Viking (NASA Langley) will be controlled at JPL, 
and Helios at Munich, Geormany. As a result JPL builds some spacecraft, e.g.. 
Mariner, and functions as the data gathering and communications center for the 
probe controllers, wherever they are located. It also provides institutional 
software and computer resources to the requesting Project Offices, but 
spacecraft control resides with the builder, not the DSN. 

8. 5. 2. 2 System Configuration 

The MCCC consists of three computer complexes, the Mission Computing Center 
Facility, (MCCF, three IBM 360/75), the General Purpose Control Facility 
(GPCF, a Univac 1108), and the MTCF used for Mariner. The DSN has 210 feet 
and 85 feet dishes at each of three locations, with high (117 Kbps), medium 
(51.2 and 22.05 Kbps), and low (2.4 and 4.8 Kbps) rate data lines connected 
to an IBM 360/75 in the MCCF. During operations, two 360/75s share the data 
lines and computing, although only one set of outputs is used (hot switching 
to backup is possible). The MCCF handles command bit structure generation and 
data packing/unpacking in real time, with up to six data lines simultaneously. 
The unpacked telemetry may be routed to the GPCF, MTCF or other operations 
control centers. The 1108 computer performs orbital planning and control, 
while the 360s are primarily real time processing machines, with resident 
software freezes before operational contacts to assure software integrity. 

The long time-line in JPL missions allows development of operational software 
after spacecraft launch, so that 360 software development, testing and vali- 
dation is a continuous process at the MCCF, generally on the third (offline) 
machine. Attached to the DSN before the data enters the MCCF is a network 
control computer, which continuously monitors data quality and constructs a 
Master Data Record, to duplicate the Original Data Record at the site. 
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8. 5. 2. 3 Roles and Responsibilities 

Jet Propulsion Labs of California Institute of Technology is a NASA contractor, 
and other NASA, government and JPL contractors reside at JPL. Philco-Ford 
is the JPL subcontractor operating in the data services division for manning 
and operating the Goldstone Complex with 1000 people. The 4000 total JPL 
employment includes spacecraft designers, builders and system engineers for 
the DSN. The role of JPL is different -from probe to probe, as is the util- 
ization of the JPL/DSN resources. The different probe efforts utilize the 
MCCF and JPL data services to different extents, depending on the size and 
talents of the probe program office and their support contractors. As an 
example, Pioneer 6 through 9 installed telemetry processors at the DSN sites 
to reduce telemetry and transmit it via TTY to NASA Ames, where analysts 
could telephone the MCCF to have commands transmitted. For Pioneers 10 and 
11, the telephone has been replaced by a data link from the Ames Sigma 5 
through its PDP 11 to the JPL 360/75. This link also carries the Pioneer 
telemetry. The DSN sites operate as a "bent pipe" and no longer perform 
telemetry reduction. 

8. 5. 2. 4 Identified Design/Development Concerns 

The software freeze on the 360/75 for an operation impacts software .development/ 
testing for the programs. The Support Instrumentation Requirements Document 
(SIRD), which levies support requirements on JPL and the DSN, should be 
expanded to show expected freezes in the timeline of each probe's associated 
software development cycle. JPL allocates resources by committing themselves 
to the SIRD requirements. 

Software testing has expanded from five men to 30 to reflect the intricate 
software relations in the 360/75 computers and to give more confidence in 
software development. . * 

Scheduling is accomplished by resource - DSN, MCCF, GPCF and MTCF, so that 
a space probe office must schedule each resource' weekly, rather than put the 
input into a network scheduling office which would combine all requests for 
all resources. High priorities are allocated to operations and state of 
health problems, so that the remaining operational problems are of a low level 
nature, but can impact software development. 

8;5.3 Pioneer Mission Operations Control Center Development Concerns 
8.5. 3.1 Operational Philosophy 

The Pioneer Mission Operations Control Center (PM0CC) capabilities have been 
developed to control two spacecraft (SC), Pioneers 10 and 11. ‘Because the 
Pioneers are nearly fly-by-wire, most changes in the SC are commanded from 
the ground. Only a few emergency shutdowns are accomplished automatically 
by the SC. This imposes real-time state of health monitoring of every SC 
subsystem on the MCC. To meet this requirement, pre-programmed command 
sequences to shut down a subsystem are stored at the MCC and at each Deep 
Space Network (DSN) station. Extensive DSN loss of communications procedures 
are necessary to preserve the SC in the event of MCC-DSN communication outages. 
With a one way RF delay of 50-60 minutes, there is time for the MCC to call 
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SC subsystem specialists in to help on equipment problems while pre-programmed 
commands are being set. The large round trip delay and fly-by-wire nature of 
the SC have caused the MCC to be designed. around real time state of health 
checks and having/updating elaborate contingency command plans to "safe" the 
SC until a subsystem specialist can perform detailed evaluation of - the sub- 
system. 'Quick look" telemetry reduction is performed in the MCC for 
functional command verification. This includes gain changes, telemetry mode 
changes, attitude and control system configuration changes, etc. 


The MCC was designed from the start (it is a converted conference room) for 
the Pioneer Mission, and for budgetary reasons maximum use of prelaunch 
ground test computers for flight support is a driving concept. The same office 
that operates the PMOCC also acquired the spacecraft; therefore, the systems 
contractors were responsive to developing the ground test fixtures for their 
dual roles. 


8. 5. 3. 2 System Configuration 

The PMOCC has three Xerox Sigma 5 computers, two of which were used for space- 
craft checkout, and two PD P II communications concentrators. A Sigma 5 and 
POP II are dedicated to each Pioneer, with the third Sigma 5 performing 
offline processing, with the capability to be switched to online real-time 
support. The system has evolved from heavy reliance on JPL 360/75 computers 
for DSN site support to performing all real time functions in the PMOCC, with 
JPL providing metric orbit reduction and calculations for course changes. This 
change was made to reduce the effects of software freezes on the JPL 360/75 
caused by a critical phase of any of the spacecraft sharing the DSN. The JPL 
360/75 has resident routines supporting each of the spacecraft, and it has 
been necessary at times to freeze all software development in order to pre- 
vent changes on the program's software from disrupting the computer during a 
critical portion of another program's flight. Moving this application soft- 
ware to the PDP II and Sigma 5 has minimized the impact of these freezes on 
PMOCC software development. The real time support positions are a controller 
for each Pioneer and a technical assistant for both. These personnel command, 
read telemetry, and assure state of health of the SC. Offline processing of 
Master Data Records for the DSN sites is performed around the clock. Experi- 
menters and subsystem specialists are on call, and perform other functions 
while the spacecraft are in the cruise mode. The manning jumps during contact 
periods, and the offline processing changes to provide "quick looks 1 ' at sub- 
system data. The intent in the PMOCC design is to provide the minimum resources 
necessary to do the job, with a large cross-pollenization among the center 
personnel . 

8. 5. 3. 3 Roles and Responsibilities 

The Pioneer mission is a typical case where the Space Project Office (SPO) 
procures both the spacecraft and the ground data processing system, with JPL 
and the DSN providing the data collection resources. Present NASA mission 
operations personnel number 20, with 52 Bendix support people in four groups* 
Flight Operations, Data, Mission ’Analysis , and Launch Operations. Flight 
Operations are the controllers and technical assistants, performing' SC 
control, real time telemetry readout of the science and SC equipments, and 
real time interfacing with JPL and the DSN. The Data group operates the 
computers, and accomplishes hardware and software development to support 
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the mission. The Mission Analysis and Launch Operation groups have various 
roles that change with the mission phase. Both NASA and Bendix are flexible 
in the roles that the offline personnel perform as the mission progresses. 

The software is unique to PMOCC, and has been developed by the SPO, including 
the launch support software. The hardware has been salvaged, rented and con- 
tracted for, with manufacturer maintenance wherever possible. The maintenance 
contractor performs all modifications to his equipment. Bendix performs 
system maintenance mods, interconnects, etc., to the equipment otherwise 
unsupported. These include the consoles, bit syncs, and telemetry station. 

JPL's role is that of data gatherer and DSN interface, and also provides the 
use of high cost resources, such as the orbit determination and some image 
processing equipment. 

The trend has been to concentrate the real time functions at PMOCC, minimizing 
dependence on the JPL computers for DSN support. A major problem is DSN 
resource allocation, with several programs requesting maximum data receipt, 
and the many programs competing for the same resources. Weekly scheduling 
meetings handle normal conflicts, with real time changes when a spacecraft's 
health is threatened. This forces the Pioneer Mission Office to gather weekly 
requests from the scientists as inputs to the scheduling process. There is a 
DSN operations control center at JPL in voice contact with the stations, but 
normally PMOCC is in voice contact with JPL, and not the sites. 

8. 5. 3. 4 Identified Design/Development Concerns 

Resource allocation at JPL has caused PMOCC to become self-reliant wherever 
possible. Although duplicating existing capabilities, by having them at 
PMOCC, the SPO has gained development resources that would normally be 
shared if at JPL. 

The flexibility of the NASA staff is a response to the shifting workload in 
PMOCC and is an effort to broaden in-house capabilities. 

8.5.4 NASA/GSFC Development Concerns 

8. 5. 4.1 Operational Philosophy 

NASA GSFC has been developed to support satellite payloads. Current design 
objectives are to standardize the Multi satellite Control Center (MCC), and 
to automate configuration changes from one satellite pass to the next. 

Another goal is to have standardized software and operator interfaces so 
that modular improvements can be made. The prime mission of the MCC is the 
health and safety of the SC, with other Goddard divisions handling software, 
data analysis, orbit reduction, and data reduction. 

8. 5. 4. 2 System Configuration 

The MCC is built around a digital switch, SCADI, which is really three PDP 
ll-20s. These provide connections between the computers (XEROX 930s and 
Sigma 5s), PCM converter decoders, strip chart decoders, CRTs and consoles, 
and the data lines from the sites. Up to 10 simultaneous satellite supports 
are possible. In the past, each console and computer group was custom built 
for a particular satellite, but the movement to grouping common functions and 
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providing standard consoles is underway. The three SCADI computers function 
as executive, online and backup, with real time switching possible. Simple 
format conversions are also performed' in the SCADI, with an emphasis on 
automatic reconfiguration of the system as the support load changes. The 
SCADI also monitors the data blocks from site and performs real time 
corrections and diagnostics on the data. 

8. 5. 4. 3 Roles and Responsibilities 

RCA is the Maintenance and Operations contractor at the MCC, in a ratio of 
seven RCA to each NASA person in flight operations. The NASA MCC design 
staff numbers 15. Goddard requires standard interfaces from the SC builder, 
with a Support Instrumentation Requirements Document detailing the agreement. 
This formal document is regularly reviewed and is the vehicle for handling 
conflicts between SC builder desires and ground capabilities. The level of 
normal support is herein defined, and requests for more than this must be 
approved by higher NASA offices. 

X 

Wherever possible the SC contractor is asked to develop test software on 
compatible machines, in a structure so that it can later be used in flight 
operations. Structurally, NASA designates a member of the MCC project staff 
as user interface, where the definition of ground system processing of SC 
data is performed in real. time-. This man is also the responsible person for 
MCC operations in support of the SC. To assure hardware/software compatibility, 
the Control Center Systems Managers have complimentary backgrounds, and both 
must initial design reviews of all hardware and software developed for the 
MCC. No new software development is allowed until the specifications for 
the changes are approved, and the interfaces defined. 

8. 5. 4. 4 Identified Design/Development Concerns 

The GSFC MCC has become conservative in technology utilization, reflecting a 
small budget. 

A Digital Data Processing System, a minicomputer with large disk storage, 
is being procured to allow post pass playback of the entire pass over low 
quality voice lines. This system will eliminate the shipping of range 
tapes in most cases. 

Unplanned MCC processing changes are handled with software changes wherever 
possible, reflecting the shorter development cycle of minor program changes. 

The MCC design is frozen about 3 to 4 months before launch to allow 30-45 
days for operator training and another 30-60 days for simulation and rehearsals. 
This early freeze has become necessary to confidently assess MCC readiness. 
Changes are allowed only at times agreed to by the M&Q and NASA staffs. This 
freeze provides a system baseline early enough to make the necessary changes. 

Two basic questions in MCC development are "What are the real requirements?" 
and "When is it really ready?". The designated member of the project staff 
to interface with the user, and the MCC design freeze are the GSFC responses 
to these' questions, along with the regular reviews of the Support Instrumentation 
Requirements Document. 
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8.5.5 DoD/SGLS Development Concerns 

This section does not include the operational philosophy and systems descriptions 
as previously defined at the other centers due to sensitivity of the data. 
However, a summary of the concerns is described below in general terms. 

Identified Design/Development Concerns - Several problem areas can be 
related to other centers as well as the Satellite Control Facility (SFC). 

Once software tradeoffs had been performed a software freeze was initiated. 

The premature freeze impacted developmental program design as well as changes, 
integration among contractors, and the relationship of the contractor and his 
role in the facility. 

The network does not have the resources to satisfy all support requirements 
levied by users, primarily due to computer, communications and tracking- 
station limitations. For months at a time, a Remote Tracking Station (RTS) 
will have no unscheduled periods if it has the capability to service both 
polar and equatorial high energy orbit satellites. The small on-line 
computers have been so heavily loaded in recent years that an emulator system 
having a five-fold increase in throughput is being procured. Eventually the 
existing software will be replaced by a new software system. The number of 
hours spent in real time support has increased each year, and currently saturates 
the computer resources. The wideband data system, where data rates to 1.024 
Mbps are supplied directly from an RTS to a Systems Project Office (SPO) 
telemetry reduction center, is expected to offload some of the Satellite 
Test Center (STC) computer requirements. 

System rehearsals are not as extensive as NASA's, because the missions tend to 
be evolutionary, with evolutionary software changes to accommodate them. The 
melding of contractor telemetry reduction facilities into the real time loop 
will be a problem in future rehearsals. 

In the Advanced Data System era (1967 - 1969), large scale concurrent 
development of new computers, buffers and software, caused many problems, 
and an interim software system with minimal changes became the standard 
system (Model A). Since then. Model A has gradually evolved into the dual 
computer processor system originally requested in the ADS era. This gradual 
evolution is now preferred for meeting new requirements. 

8.5.6 New Control Center Development Approach 

The assessment of the mission control centers in the previous .paragraphs 
was based on the particular role of that center and the specific types of 
missions they supported. Several items appear significant in determining the 
development philosophy for a new control center. 

Planning and close coordination has been a key to the development of new MCC's. 
Problems were solved more easily in the past by utilization of a detailed 
development plan and close coordination and review with the developers and 
implementators. Close coordination provided early identification of problem 
areas and allowed flexibility for long lead time changes. 
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The development plan should specify a system that has growth potential to 
meet future requirements. The upgrading of a system is preferred fay a 
gradual evolutionary process rather than by drastic changes. 

The MCC should have the capability to restructure its systems on its own 
timeline. Or the MCC should thoroughly understand the ramifications of 
utilizing institutional resources (hardware/software) that may be in contention 
by other programs. In the same vein, the MCC should not contend for its own 
resources, .i.e., software development on a machine that is providing mission 
support. 

The MCC development should be streamlined, deleting redundant operations and 
development cycles. For instance, test software should be developed on MCC 
compatible machines, such that the software can later be used in flight 
operations. 

The MCC should establish a definite interface with other facets of the 
data flow; NASCOM, GSFC and the STDN/TDRSS- subnets. The MCC should realize 
a continued increase in support requirements from other programs may negate 
those services once supplied by NASCOM or GSFC (Orbit determination), etc. 

The MCC should also establish a definite interface with its users, defining 
the capabilities it can provide and the requirements the user systems must 
meet to utilize these capabilities. This will prevent the user from over- 
loading MCC systems. 
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A significant number of missions in the Space Transportation System model 
set cannot be achieved by the Earth Orbiting Shuttle Vehicle. This is 
because its performance capabilities limit it to near-earth missions. To 
extend the capabilities of the System,' an additional' stage has been added to. 
the basic shuttle vehicle. The Interim' Upper Stage (IUS) performs this 
service in the 1981-1983- time frame. 

Implicit in the addition of the IUS is the necessity for a ground network 
and control' center for monitoring and/or control of the IUS vehicle during i-ts 
mission. The complexity and, therefore, the development costs of the IUS 
Control Center, is a function of the requirements resulting from the mission 
profile and the autonomous capabilities of the onboard avionics of the IUS 
vehicle. 

IUS vehicle avio'nics have the greatest influence on operational autonomy. 
Onboard autonomy establishes the -required degree of ground control 
and monitoring. Allocation of functions, such as navigation, influence the 
avionics requirements. From a mission standpoint, this function must be 
performed, and if not accomplished onboard, it must be done by the ground. - 
It follows that the more autonomous IUS operation permits a decrease in 
ground operations. The following are characteristics of the two autonomy 
levels: 

• Level A Autonomy 

• - - Existing Vehicle 
Tone command system 
No interface with onboard computer 
No navigation or target update capabilities 

• Level B Autonomy 

Modified vehicle 
Digital -command system 
Interface with onboard computer 
Navigation and target update capabilities 

This section presents the baseline operations plan for an IUS- vehicle 
designed for operation at Level B autonomy. The Baseline Operations Plan 
includes the ground support functional organization, mission controller- 
functional requirements, and' operations support requirements. Cost estimates 
are presented for software (ground and airborne*), hardware; facilities and 
services which are directly chargeable to the support of IUS mission 
operations . 

9.1 MISSION PLAN DESCRIPTION 

This section defines the reference missions, which is structured to include 
the covering set of mission requirements (required mission functions), which 
provide a basis for selecting and sizing operational support elements. 
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9.1.1 Covering Set of Mission Requirements 

Modular timel-ines were developed which capture the scope of operational 
activities surrounding trajectory based events. Section 3.2 presents and 
discusses the modules making up the modular timelines. It is sufficient 
for the purposes of this section to note that the reference mission includes 
all unique operational activities of an IUS mission. 

The modules are: the Orbiter Launch Operations module, which covers the 

period from launch preparations through IUS deployment, enable and first 
coast period; the On-Orbit Coast module, which covers the interim on-orbit 
navigation, guidance and control state between active mission modules; the 
Main Engine Burn module, which is utilized each time a major manevery is 
required; the Payload placement module, which covers the payload (Spacecraft) 
enable and deployment functions; and the Kick Stage Separation module, which 
defines the functions required to activate and deploy a kick stage. 

9.1.2 Single Spacecraft Deploy Mission Timeline 

The mission chosen as the reference for determining control center require- 
ments, deploys a Spacecraft at geosynchronous 'altitude. Figure 9. 1.2-1 
illustrates the mission geometry and Figure 9. 1.2-2 illustrates the combined 
STDN/TDRS converage. Figures 9. 1.2-3 and 9. 1.2-4 illustrate the TDRS-only 
and S.TDN-only ground tracks and coverage. 

9.2 FUNCTIONAL ORGANIZATION 

Figure 9. 2.0-1 presents an overview of the recommended mission control 
organization. The basic line structure for mission control organization 
will begin with Mission Director at the apex to whom reports the Orbiter 
Operations Director, the IUS Operations Director and the Spacecraft Opera- 
tions Director. Coordination between the three involved control agencies 
will be direct, with the decision authority vested in the Mission Director 
to resolve conflicting subordinate level requirements. The chart as drawn is 
relevant to on-orbit operations and does not include the launch operations 
involvement. 

The IUS Operations Director is responsible for all aspects of control of the 
IUS including the facilities maintenance and operations, vehicle systems, 
flight dynamics, mission planning and special function organization. 

Reporting to the IUS Operations Director are a Facilities Management group, 
a Vehicle Systems group, a Flight Dynamics and Mission Planning group 
devoted to real-time analysis of flight dynamics, real-time retargetting, 
and restructuring of the mission and the preparation of the initial mission 
plans, and a Special Functions group. The Special Function operation will 
be Spacecraft particular or experiment related function. 
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Figure 9. 1.2-1. F/US Spacecraft Delivery Mission Profile 
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Figure 9. 1.24. E/US Geosynchronous - STDN Only Case 
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Figure 9.2.0-1. i US Mission Control Organization 





9.2.1 Flight Control Organization 

The flight control organization begins at the second tier of the mission control 
organization. 

During operational periods the IUS Operations Director assumes total authority 
over all control center functions, including the Facilities Management group. 
During non-operational times, the Facilities Supervisor directs the support 
personnel. This report is concerned only with the operational relationships. 

The Flight Control Group is responsible for the IUS vehicle and the successful 
accomplishment of its mission. It is divided into three teams: Vehicle 

Systems, Flight Dynamics, and Special Functions. The Facilities Management 
group operationally reports to the IUS Operations Director but assumes a 
support, not control activity. Personnel manning the positions in the Flight 
Control Group will be experienced engineering personnel with corresponding 
design and test responsibility for the IUS system which they monitor and 
control . 

Flight Control' personnel are responsible for the real-time control of the IUS. 
Preparation for these responsibilities requires extensive study and Control 
Center "on-console" traning for each mission. Backup personnel must also 
be equally prepared to assure timely and qualified flight support continuation 
in contingency situations. Flight controllers must be completely abreast of 
IUS vehicle systems, the IUS Control Center data display, command system and 
all details concerning the specific mission being flown. 

The basic responsibilities of each team position are listed below: 

Vehicle Systems Group - The Vehicle Systems Group, reporting to the Vehicle 
Systems Engineer, monitors real-time IUS data and maintains cognizance of 
the IUS operational status. The team is functionally divided into four areas 
of vehicle responsibility: propulsion, avionics, networks, and communications. 

Flight Dynamics/Mission Planning Group - The Flight Dynamics Group, reporting 
to the Flight Dynamics Engineer, is responsible for IUS vehicle trajectory 
management. This entails the continual comparison of predicted, actual and 
desired vehicle trajectory and the generation of corrective maneuver seq- 
ences. Functional divisions of the group are Guidance, Dynamics and Data 
Selection. 

Special Functions Group - The Special Functions Group is responsible for 
monitoring Spacecraft status and most activity during deployment 
operations. It is probable that Special Functions Group personnel will vary 
with the type of Spacecraft being serviced. 

9.2.2 Facilities Management Organization 

The Facilities Management Group is composed of three teams, Data Systems, 
Maintenance and Operations and Software Support. These teams insure and 
are responsible for control center readiness and operational integrity. 

These teams report directly to the Facilities Supervisor during mission 
operations. 
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The Facilities Management Group assists the Flight Control Group with commands, 
communications, and displays, and maintains and operates all equipment within 
the facility. This team also provides logistic support for continuous control 
center operation. The Software Support Team operational responsibility requires 
a continual availability of personnel capable of explaining and/or handling 
software related problems. 

9.2. 2.1 Organization and Reporting Responsibility 

Figure 9. 2. 2-1 presents the Facilities Management Group organization. The 
organization is functionally divided into three groups: Data Systems, Mainten- 

ance and Operations, and Software Support. Division is along functional lines, 
although there is overlap between all three groups. 

The leader of the Facilities Management group is known by two titles, used 
interchangeably; as the Flight Support Director or as the Facilities Super- 
visor. This is indicative of the dual role he has in mission operations. 

During the real-time period, he reports to the Flight Director and is 
responsible for overall support to the Flight Control personnel. During non- 
real -time operations, he supervises the maintenance and checkout of the facility 
equipment. In both roles, the Data Systems, Maintenance and Operations and 
Software Support teams report administratively to him. 

The Data System Supervisor oversees the activities of the Command, Telemetry 
and Site Select Technicians. 

The Maintenance and Operations Supervisor oversees the activities of the 
computer operators, computer monitors, data flow technician, data processing 
engineer, voice technician and display technician. 

The Software Support Supervisor heads a team of specialists who are knowledgeable 
in ’the mission profile, vehicle systems, executive/control center, and simulation 
software. These personnel provide expertise during real-time operations to re- 
solve software-related problems, and provide update and mission-peculiar software 
modifications during non-real-time periods. 

9. 2. 2. 2 Data System Support Group Responsibilities 

The Data Systems Group is composed of personnel who are actively involved in 
operating the support systems in real-time. These personnel interface between 
the flight control personnel and the support equipment, acting as aides and 
assistants to the flight control personnel. They occupy the same functional 
relationship to the flight controllers as an aircrew does to a pilot. They 
are operators, as opposed to maintenance personnel, who interpret data in 
support of flight controllers. 

There are three subdivisions under Data Systems: telemetry, command and site 

select. 

It is the responsibility of the telemetry technician to monitor telemetry 
data flow status and to initiate any corrective actions required to maintain 
telemetry data flow throughput to the flight control consoles. The telemetry 
technicians will operationally respond to any flight controller's request for 
telemetry readouts (e.g., bit circuit, calibration data, bit-error rate, etc.), 
and to the Facilities Supervisor through the Data Systems Supervisor.- 
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Figure 9. 2. 2-1. Facilities Management Group Organization 
















The command technician is responsible for the construction of command loads 
in the appropriate format for uplink, the transfer of that load into an up- 
link data buffer, and monitoring the uplink and verification-of-receipt 
of the command. The command technician also must track down the sources of 
errors in the command data flow system, and cause corrective action to be 
initiated. The command technician responds to any flight controller having a 
command panel and to the Facilities Supervisor through the Data Systems 
Supervisor. 

The site select technician is responsible for interface between the IUS Control 
Center and the support network (TDRS and STDN). He will coordinate the 
selection of the appropriate site to receive telemetry or to uplink commands 
to the IUS. He is further responsible for checking the operational status at 
each site and for planning backup or alternate routings for the data connections 
with the IUS. He is responsible for providing optimum data transfer between 
the IUS and the Mission Control Center. The site select technician reports to 
the Data Systems Supervisor, and has no direct contact with the flight controllers. 

The Data Systems Supervisor is responsible for overall operation of the data 
systems supporting the flight controllers. He manages the computer operation, 
monitors computer status, selects the on-line CPU and monitors switchover. In 
addition, he has organizational responsibility for the performance of the 
telemetry technician, command technician and site select technician. 

9. 2. 2. 3 Maintenance and Operations Group Responsibilities 

The Maintenance and Operations (M&O) Group is composed primarily of equipment 
maintenance specialists who are responsible for the operability of all Mission 
Control Center support equipment. 

The M&O personnel have no direct interface with the flight controllers in the 
operational sense, but must be responsive in real-time to requests to fix the 
equipment. In the pre-mission non-operational phases, the M&O technicians 
must perform periodic maintenance on the equipment and conduct proof-of-perform- 
mance tests of equipment operation. During operational periods, the M&O 
technicians monitor equipment operation, and are alert to malfunction in- 
dications. They will notify the M&O Supervisor when equipment must come 
off-line for repair, and will coordinate equipment configuration with the Data 
Systems Technicians. 

Computer operators operate the data processing equipment associated with real- 
time flight control operations, and are responsive to requests from the Data 
System technicians. They are administratively responsible to the Maintenance 
and Operations Supervisor. 

The computer monitors are responsible for mission computing, scheduling and 
control of non-mission job-shop work, CPU performance and maintaining of the 
system data base. Computer monitors and computer operators function inter- 
actively to maintain the data processing equipment configuration at peak 
efficiency. The computer monitors report administratively to the M&O 
Supervisor. 
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The Data Processing System Engineer is responsible for the maintenance of the 
data system CPU and peripherals. This function is best performed by a 
maintenance contractor which will provide a DPS engineer to NASA who will 
respond as a member of the Flight Support Team, Maintenance and Operations 
group. This function requires highly specialized skills and training normally 
available only from the Data Processing System manufacturer. During operational 
periods, the DPS engineer reports functionally to the M&O Supervisor. During 
non-mission periods, he executes the requirements of a Data System Maintenance 
Contract. 

The Data Flow Technician is responsible for all equipment interfacing between 
the data system and the outside world. This will include all MODEMS and line 
termination equipment which interface with the network. During operational 
periods, he will monitor the equipment performance and select the terminals 
having best operational characteristics. During non-operational periods, he 
will perform periodic maintenance and conduct proof-of-performance tests on 
the equipment. He reports administratively to the M&O Supervisor. 

The Display Technician is responsible for maintaining the equipment which 
interfaces with the flight control personnel; consoles, console displays and 
group displays. During operational periods he monitors the operation of the 
equipment and stands-by to execute immediate replacement or repair of the 
equipment. During non-operational periods, he will perform periodic main- 
tenance and conduct proof-of-performance tests. The Display Technician 
directly interfaces with and is responsive to direction from the flight 
control personnel in real-time, and reports administratively to the M&O 
Supervisor. 

The Voice Technician is responsible for all voice communications internal to 
the control center, and for all voice communication with external operational 
entities. He is the primary interface with the common commercial carriers 
which provide communications service to the Mission Control Center. The 
Voice Technician maintains all communications loops in operational configuration, 
and reports both functionally and administratively to the M&O Supervisor. 

9. 2. 2. 4 Software Support Group Responsibilities 

The software support team will consist of high-level software personnel who 
are functionally familiar with the overall software and its capabilities. 

Because the software is the critical element in achieving the Mission objectives, 
the software support team must be able to respond rapidly to software-related 
questions and actively participate with flight support group team members in 
the effective utilization of the software capabilities. 

The software support supervisor will be responsible for the continuous 
software support and development activities after intial delivery of the 
software system. He will provide the interfaces with NASA and contractor 
personnel for all software-related functions. To provide the necessary inter- 
faces, he will have a staff of software/ hardware systems personnel to perform 
the following functions: 
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• Software Reviews 

• Configuration Control 

• Software Audits 

• Continuing Customer Interfaces 

• Project Status Reporting (Costs and Schedules) 

• Document Control 

A software development section will be responsible for the control updating of 
the software to support changing requirements. Previous space programs of 
long duration, such as Apollo, have shown' that the software within the control 
center will continue to evolve throughout the' lifetime of the program. The 
RTCC software, for instance, grew in size by a factor of 50 percent over the 
lifetime of the Apollo program. This growth was distributed among all the 
elements of the software. 

To address the requirements for continual software change, the software 
development activity has been organized according to the functional software 
requirement areas: 

• Mission Profile 

• Vehicle Systems 

• Executive/Control Center Support 

• Simulation and Training 

Mission Profiles - The mission profile group will be responsible for main- 
tenance and support of the software which addresses the mission profile 
function. These software elements are: 

• Orbit Trajectory Determination 

§ Orbit Trajectory Computations 

a Mission Planning 

Vehicle Systems - The vehicle systems group will be responsible for maintenance 
and support of the uplink and downlink processing software. 

Executive/ Control Center Support - The executive/ control center support areas 
of the control center software will be highly volatile because of the changing 
display requirements and response time changes as a result of mission changes 
and vehicle changes. This support group will maintain and support all changes 
to these areas. 

Simulation and Training - The simulation and training software group will be 
responsible for modifications- of the simulation software system which reflect 
changes in -mission profiles and vehicle configuration. In addition, this group 
will conduct training sessions in software capabilities for the flight support 
group and will support the use of the simulation system during ground controller 
training. 

The central computers of the control center will be utilized for real-time 
mission support, training of flight support personnel, software development, 
and normal jobshop operations. It is assumed that for cost effectiveness, the 
computer operations will be three shift/day, seven day a week operations. 
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9-2.3 Recommended Manning Level 

The following paragraphs describe the recommended manning levels for IUS 
operations. Major divisions in manning are (1) Facilities Maintenance or 
Flight Support Staff and (2) Flight Control Staff. 


9. 2. 3.1 Facilities Maintenance or Flight Support Staff 

There are 30 personnel required to staff the Facilities Maintenance or Flight 
Support- organization on a continuing basis. Table 9. 2. 3-1 presents a break- 
down of the staff requirements. 


The size of the staff is established by the real-time support requirements. 
However, the staff, during -non-mission and non-training periods, is to be 
utilized to perform mission preparations and maintenance jobs. This multi- 
plexing of personnel is cost-effective in that it spreads the productive 
work load of the permanently assigned personnel more evenly across the 
operational periods. 


Table 9. 2.3-1. Flight Support Staff Requirements 


' 

— MM 

NOT OF 

SHIFT 

TOTAL 

POSITION 

MANNING 

CONSOLES 

DENSITY 

REQ, 

FLIGHT SUPPORT GROUP 

FLIGHT SUPPORT DIRECTOR 

1 

1 

2 

2 

DATA SYSTEM SUPERVISOR 

1 

1 

2 

2 

COMMAND 

1 

0 

2 

2 

TELEMETRY 

1 

1 

2 

2 

SITE SELECT 

1 

0 

2 

2 

MAINTENANCE AND OPERATIONS 

1 

1 

2 

2 

DATA FLOW 

1 

1 

2 

2 

DPS ENGINEER 

1 

0 

2 

2 

VOICE TECH 

1 

0 

2 

2 

DISPLAY TECH 

1 

0 

2 

2 

COMPUTER SYSTEM MONITORS 

2 

1 

2 

4 

COMPUTER OPERATIONS 

2 

0 

2' 

4 

COMPUTER SUPPORT 

2 

0 

1 

2 

TOTALS 

16 

6 

25 

30 


9.2. 3.2 Flight Control Staff 

There is a specific minimum staff required to control the IUS vehicle during 
mission operational periods. For the IUS program, that staff requirement is 
30 flight control engineers. The flight control organization is a required 
sustaining engineering staff which may be utilized during non-mission periods 
in performing preparation tasks, such as training, scheduling, and interface 
type operations-. As with the flight support staff, the spreading of effort 
across the period of operations is a cost-effective utilization of the 
flight control staff. Table 9. 2. 3-2 presents' the flight control staff 
requirements . 
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Table 9.2.3-2. Flight Control Staff Requirements 



MAX 

NUM OF 

SHIFT • 

TOTAL 

POSITION 

MANNING 

CONSOLES 

DENSITY 

REQ. 

FLIGHT CONTROL GROUP 

TUG OPERATIONS DIRECTOR 

1 

1 

2 

2 

VEHICLE SYSTEMS ENGINEER 

1 

1 

2 

2 

PROPULSION 

1 

1 

2 

2 

STAGE SYSTEMS 

1 

1 

2 

2 

CONSUMABLES 

• 1 

0 

2 

2 

NETWORKS 

1 

1 

2 

2 

COMMUNICATIONS 

1 

0 

2 

2 

AVIONICS 

1 

1 

2 

2 

GUID. AND NAV. 

. 1 

0 

2 

2 

SEQUENCE 

1 

0 

2 

2 

GUIDANCE 

1 

1 

2 

2 

DYNAMICS 

1 

1 

2 

2 ■ 

DATA SELECTION 

1 

1 

2 

. 2 

FLIGHT DYNAMICS OFFICER 

1 

1 

2 

2 

SPECIAL FUNCTIONS 

1 

1 

2 

2 

TOTALS 

15 

11 

30 

30 


9. 2. 3. 3 Derivation of Manning Requirements 

Before arriving at an estimate of recurring' cost, it was necessary to invest- 
igate the impact of simultaneous missions and mission module overlaps on the 
level of support required. 


To accomplish this impact analysis, IBM developed a mission density factor 
program. This program creates a launch schedule and mission module timing 
schedule for which the overlap of missions and mission modules is developed. 
At the same time, gaps in the schedule are identified which can be used for 
training and simulation tasks. 


Outputs from the mission density factor drive the following dependent cost 
relationships. 

Computer Support Personnel - Establishes the hours the computer 

is committed. 


Sustaining Flight Control 


Flight Support Personnel 


Flight Control Consoles 


Network Rental 


- Establishes the number of shifts 
required and the number of personnel 
required. 

- Establishes the number of shifts 

. required and the number of personnel 
required. 

- Establishes the number of consoles 
required by type. 

- Establishes the number of hours required 
in one year of TM, Command and Tracking 
Service 
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9. 2. 3. 4 Sustaining Support Personnel 

The mission density function establishes the computer commit hours per year, 
which- then is converted to equivalent men required to. provide computer 
support. 

The mission density function aiso establishes the shift density factor for 
flight support personnel. The level of effort established for flight support 
is constant. No provision, has been made to assign, other duties- to the flight 
support staff. 

The mission density function provides a shift density factor and console 
multiplier which are combined to create a manpower requirement estimate. The 
level of effort established for flight control support is constant. No 
provision has been made to assign other duties to the flight control staff. 

9. 2. 3. 5 Ground' Software Maintenance 

Since software problems will be identified throughout the entire software 
module set, it is necessary to provide resident personnel familiar with every 
area. The number of personnel required is dependent upon the size, complexity, 
criticality and level of mission-to-mission changes for the program. Twenty- 
five programmers have been estimated as required to perform the ground software 
maintenance. 

9. 2. 3. 6 Flight Software Maintenance 

Flight software maintenance is similar to ground software maintenance in. 
concept. It is necessary to .maintain a staff of personnel who are-familiar . 
with each of the four basic programs, and to maintain capability to define, 
code and verify the flight programs. Twenty-one programmers are required to 
supply mission -modifications, coding and verification for the four baseline 
programs. 

9.3 FLIGHT CONTROL FUNCTIONAL REQUIREMENTS 

The following paragraphs define the nominal and contingency functions of the 
Flight Control Organization. 

9.3.1 Vehicle Systems- Group 

The vehicle systems group is required for EIUS mission control.- The vehicle 
system group is formed of a leader and four- subordinate organizations. The 
leader, the Vehicle System Engineer, is responsible for all vehicle systems, 
and will coordinate the analysis- of vehicle systems and issues all commands 
to 'the vehicle which are directly related to hardware functions, as opposed 
to trajectory shaping functions. The vehicle systems engineer is a primary 
consultant and recommends implementation -of mission rules based upon the 
state of affairs at a -given time during the mission. 

Reporting to the Vehicle System Engineer is the propulsion group, which is 
responsible for the main propulsion system, the attitude control propulsion 
system, pneumatics, propellant tank management, main engine performance 
and main engine support devices, maintaining knowledge. of consumables 
utilization, structures and thermal control considerations. 
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The second major division under the vehicle systems group is the avionics 
support team. The avionics support team is responsible for the analysis of 
all hardware relevant to the guidance, navigation and control system and the 
attitude and thrust vector control systems. Two suborganizations beneath the 
avionics organization are the Guidance and Navigation Engineer and the 
Sequential Systems Engineer with the primary division between those two being 
between sensor hardware and computational hardware analysis. 

The third breakdown beneath the vehicle system engineer is the network 
responsibility. All functions relevant to the electrical power capability, 
battery charge, and electrical loads are the responsibility of the Networks 
System Engineer. 

The fourth subdivision is the Communications System Engineer. This engineer 
is responsible for maintaining cognizance of the status of the communications 
systems for uplink, downlink, and tracking functions. Additionally, he is 
responsible for the generation of commands and the coordination of uplink 
requirements with the network. He maintains cognizance over the signal 
conditioning, multiplexers, transducers, and RF components of the telemetry 
systems. 

Figure 9.3. 1-1 presents the vehicle systems group organization. 

9.3.2 Flight Dynamics and Mission Planning Group 

The flight dynamics and mission planning organization is concerned,' in the pre- 
mission period, with the structure and generation of the optimum mission 
trajectory based upon the Payload, Orbiter and EIUS operational constraints. 

In real-time the flight dynamics organization is responsible for trajectory 
planning and shapeing, all decisions based upon trajectory considerations, 
planning of maneuvers, commanding maneuvers, plus maintaining knowledge of 
the Orbiter and EIUS ephemerides. 

Figure 9.3. 2-1 presents the Flight Dynamics and Mission Planning Organization. 
There are three basic subdivisions beneath the flight dynamics organization: 
Guidance, Dynamics and Data Selection. The Guidance engineer is responsible 
for monitoring vehicle performance during guidance phases, the analysis of 
drift in references, the optimization of corrective maneuver, the recommendation 
of command action to accomplish those maneuvers, and the selection of the 
optimum guidance scheme for a particular mission maneuver. The Dynamics 
engineer is responsible for maintaining knowledge of vehicle mass characteristics, 
the monitoring of the trajectory, and the overseeing of the trajectory com- 
putations which result in the ephemeris tables for the EIUS and Orbiter. The 
Data Select engineer is responsible for insuring the validity of tracking 
information, monitoring the smoothing, differential corrections and weighting 
factors pertinent to the construction of the trajectory, the selection of a 
tracking site and/or the monitoring of the TDRS range and range rate information, 
coordination of site hand-over and providing assistance to the network in 
assuring that the appropriate tracking information is available to the EIUS 
Operations Control Center as needed. 
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Figure 9.3. 1-1. Vehicle Systems Group Organization 













Figure 9.3.2-1. Flight Dynamics and Mission Planning Organization. 


9.3.3 Special Functions Group 

Provision has been made for a "Special Function" group to be incorporated into 
the basic I US operations organization in order to accommodate experiment 
packages or unique Spacecraft missions that may require additional specialists 
for specific functions. Figure 9. 3.3-1 shows the Special Functions group 
organization. 

The one permanent member of the Special Function group is the Special Functions 
engineer who will be responsible for all payload operations from predeployment 
monitoring and housekeeping through interface with the principal investigator. 

9.3.4 Facilities Management Group 

The Facilities Management Group (reference Figure 9. 2.2-1) is responsible 
for providing the necessary data, command and network configuration coor- 
dination required to support the EIUS mission. All scheduling interfaces 
with the network operations will be conducted by this team. Additionally, 
all hardware and software maintenance required in the EIUS control center will 
be provided by the facility management group. 
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There are three basic organizational entities reporting to the facilities 
management supervisor. Those organizations are the data system subgroup, 
the maintenance and operations subgroup and the software support team. 

The data system supervisor has three groups reporting to him; a command 
group, a telemetry group, and a site select group. The data system supervisor 
collectively has responsibility for overall operation of the computer complex 
and is responsible for telemetry, tracking and command interface with the 
support network. 

The maintenance and operations organization is responsible for the operability 
of the data processing and display equipment, communications equipment, the 
overall facility capabilities and the mission support logistics. The 
maintenance and operations supervisor has reporting to him seven specialists: 
computer operators, a data flow specialist, a data processing system maintenance 
engineer, a computer monitor, display technician, and voice technician. 

The software support team is responsible for maintaining the support soft- 
ware in an operable condition, coordinating the problems with the flight 
director as required and for answering of all software related questions, 
including operational utilization of the software by the flight controllers. 

9.3.5 Ground Software Support Group 

It is reasonable to assume that there will be changes from mission to mission 
in the IUS Control Center software. To effect these changes, a Software 
Support Group will be required. This organization is depicted in Figure 
9. 3. 5-1 and will be discussed in the following paragraphs. 
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Figure 9.3.3-1. Special Functions Group 
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Figure 9.3.5-1. Software Support Group 











9.3,5. 1 Project Manager/Project Office 

The software project manager will be responsible for the continuous software 
support and development activities after initial delivery of the software 
system. He will provide the interfaces with NASA and other contractor 
personnel within the control center for all control center software-related 
functions. To provide the necessary interfaces, he will have a project office 
staff of five software/hardware systems personnel to perform the following 
functions: 


• Software Review 

t Configuration Control 

• Software' Audits 

• Continuing Customer Interfaces 

• Project Status Reporting (Costs and Schedules) 

• Document Control 

9. 3. 5. 2 Software Development Section 

The software development section will be responsible for the continual updating 
of the software to support changing requirements. Previous space programs of 
long duration, such as Apollo, have shown that the software within the control 
center will continue to evolve throughout the lifetime of the program. The 
RTCC software, for instance, grew in size by a factor of 50 percent over the 
lifetime of the Apollo program. This growth was distributed among all the 
elements of the software. 

To address the requirements for continual software change, the software 
development activity has been organized according to the functional software 
requirement areas. As shown in Figure 9. 3. 5-1, these areas are: 

• Mission Profile 

• Vehicle Systems 

• Executive/Control Center Support 

t Simulation and Training 

9. 3. 5. 3 Mission Profile 

The mission profile area will be responsible for maintenance and support of 
the software which addresses the mission profile function. These software 
elements are: 

• Orbit Trajectory Determination 

• Orbit Trajectory Computations 

• Mission Planning 

9. 3. 5.4 Vehicle Systems 

The vehicle systems group will be responsible for maintenance and support of 
the uplink and downlink processing software of the I US Control 'Center. 
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9. 3. 5. 5 Executive/ Control Center Support 


The executive/control center support areas of the software will be highly 
volatile because of the changing display requirements and response time 
changes as a result of mission changes and vehicle changes. This support 
group will maintain and support all changes to these areas. 

9. 3. 5. 6 Simulation and Training 

The simulation and training software group will be responsible for modifications 
of the simulation software system which reflect changes in mission profiles 
and IUS vehicle configuration. In addition, this group will conduct training 
sessions in software capabilities for the flight support group and will support 
the use of the simulation system during flight controller training. 

9.3. 5.7 Computer Operations Section 

The central computers of the control center will be utilized for real-time 
mission support, training of flight support personnel, software development, 
and normal jobshop operations. It is assumed that for cost effectiveness, 
the computer operations will be three shift/day, seven day a week operations, 
and is staffed accordingly. Included within this section are keypunch services, 
tape librarians, administration personnel, management personnel, customer 
engineers, as well as the computer operations personnel. 

9.4 ORBITER CREW FUNCTIONAL REQUIREMENTS 

There is minimal IUS operations interface with the Orbiter Crew. What 
interaction exists, is, for the most part, monitoring of caution and warning 
parameters, and stand-by to back-up critical sequences in the event of 
contingency situations. 

9.5 OPERATIONS SUPPORT REQUIREMENTS 

This section summarizes the hardware, software, and data system required to 
support real-time IUS flight operations. 

9.5.1 Airborne Operations Support Hardware 

The IUS Avionics System has the dominant impact upon mission operations. The 
implementation of control decisions can be shifted between the onboard 
avionics and the ground based electronics. This shift is a function of the 
level of autonomy to which the IUS is designed. 

In general, the shift of control authority to the onboard system is desirable, 
since the implementation of any control of the ground carries with it a heavy 
overhead for transfer of data from the vehicle relative to its physical 
conditions to a ground based information assimilator. This overhead (tracking, 
telemetry, command, etc.) contributes nothing to the decision processes. 

Figure 9. 5. 1-1 presents the IUS level B avionics system, which houses the 
airborne operations support hardware. 
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Figure 9.5. 1-1 .Expendable IUS Level B Avionics Configuration 
















The baseline EIUS used for the IBM analysis and costing is a representative 
vehicle modified to accomplish the EIUS mission. The EIUS avionics are 
basically simple and designed for a short duration mission. The major addition 
is the STDN/Orbiter compatible communications, with minor mods for the 
sequencing, RMIS converter, and software. Interface provisions for the 
Orbiter have also been provided. 

The digital computer with a 16K, 24 bit storage provides the onboard 
computation capability. The IMU provides an inertial reference system and 
the computer provides the control signals for the hydralics and the sequencing 
for the ACS engines and electrical systems. Two batteries provide the onboard 
power requirements. Telemetry is collected by the remote multiplex unit (RMU) 
and formatted by'the RMIS. The communications provide tracking, telemetry and 
command interface with the ground and Orbiter. 

The interface adapter contains the provisions for making the EIUS external 
interface compatible with the Orbiter and GSE. The EIUS command decoders 
also contain additional provisions for computer inputs. Spacecraft commands 
and EIUS sequencing. Spacecraft telemetry could be integrated with EIUS 
telemetry by inputs to the EIUS RMU's. 

9.5.2 Ground Operations Support Hardware 

The hardware analysis is divided into two parts; i.e., that utilized by the 
mission support staff (consoles, communication panels, etc.) and that re- 
quired for the IUS Control Center Data System. 

9.5.2. 1 Data System 

The data system in the IUS Control Center is the system by which incoming, 
outgoing, and intercenter intelligence is processed, routed and managed. The 
data system is depicted in Figure 9. 5. 2-1. The computer is the central element 
of the system, and because of its significance, it has been addressed separately. 
The remaining elements of the system are discussed in the following paragraphs. 

Communications Controller - The communications controller is a device required 
for buffering and routing input and output data between the central computer 
and the data line terminations (MODEMS). Incoming telemetry and tracking data 
is checked for transmission errors, error encoding removed and then formatted 
for transfer to the central computer. Outgoing command data is received from 
the central computer, encoded into proper format and then transferred to 
outgoing transmission facilities. The unit is essentially a switch and 
storage facility for incoming and outgoing data. 

Modulator/Demodulators (MODEM’S) -MODEMS are devices required for interfacing 
with IUS Control Center transmission lines. These devices serve the function 
of modulation conversion between transmission line format and the computer 
system format for both incoming and outgoing information. 

Master Clock - The master clock is an independent time source supplying 
master time (GMT) to the central computer system. The central computer will 
then generate the differential times needed for mission control. The master 
clock will also contain a receiver for synchronization of the master clock to 
the National Bureau of Standards master clock. 
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Figure 9.5.2-1. IUS. Control Center Data System Block Diagram 


Console Discrete Interface Device - This unit serves as an interface between 
the central computer and the support staff consoles. It compiles discrete 
and digital signals into formats acceptable for use by the central computer. 
These signals include command execute pushbuttons, display request signals, 
computer control pushbuttons and miscellaneous computer cont rol discretes. 

For IUS Control Center usage, this unit will be capable of processing 
approximately 1200 individual signals. 

Digital and Discrete Drivers - The digital and discrete drivers are interface 
devices between the central computer and console displays which receive digital 
and discrete word outputs, de-multiplex these words and then drive individual 
lamps, readouts, etc. These drivers are required for all status and event 
lites, command pushbotton indication lites, digital readouts, and clock read- 
outs. For Control Center usage, the system will handle approximately 2000 
individual discretes. 

Digital TV Equipment - Digital TV Equipment (DTE) is required to convert 
computer generated display data into video and video associated signals 
compatible with the support staff console TV monitors. The DTE combines 
static background format data stored by the computer with the dynamic data 
being processed by the computer in real-time and formats the information 
for display on the TV monitors. Display refresh is performed by the DTE. 

Only updated information, that is, information which has changed since the 
last refresh cycle, is transferred’ from the computer to the DTE. 

Video Switching Equipment - The Video Switching Equipment distributes Digital 
TV data from the computer to individual console TV monitors. 
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Computer Terminal Equipment - During an IUS mission, some of the communications 
between the support staff (particularly flight controllers) and the central 
computer can be conducted most efficiently using standard terminal equipment. 
These terminals consist of a Manual Entry Device (MED) and a CRT display. 
Nominally, one display control unit (Interfacing unit to the computer) will 
be required for each combination of six of these terminals. 

Teletype Printer/ Keyboard (TTY) - A TTY Printer/Keyboard will be required in 
the Control Center for general administrative message receipt and generation. 

Communication Equipment - This equipment provides voice communications throughout 
the Control Center and" interfaces with external commercial /common carrier 
lines. For IUS/OC operation, a central switchboard will be required to provide 
the following: 

• 30 internal loops 

• 15 external connections 

• 10 PABX stations 

The PABX will be configured such that no more than five positions, will have 
the same rotary number. 

Computer Peripheral Equipment - The central computer will require standard 
peripheral equipment in addition to the Central Processor Unit (CPU) and 
memory. Standard peripheral devices such as tape drives, disc storage, 
channel control, line printer, card reader and interface adapters will be 
configured for Control Center support. 

9. 5. 2. 2 Support Staff Hardware Requirements 

The mission support analysis discussed in this document delineates various 
positions and their responsibilities to support an IUS mission. To effect 
the support from these personnel will require a means whereby information can 
be made available to them for decision and action. 

Dissemination of this information is achieved by displaying the information 
to the support staff in the form of TV displays, discrete light indicators, 
meters, etc. For convenience, pertinent indicators and computer driven TV 
displays are lodged in operator consoles according to the requirements of 
that position. 

Table 9. 5. 2-1 summarizes the equipment necessary for each position to per- 
form the required duties assigned to it. 

9.5,3 Ground Operations Support Software 

The IUS Control Center Software, which resides in the central computer, 
provides centralized processing of telemetry and radar inputs received from 
the ground network and performs other complex mathematical and logical func- 
tions in support of flight controllers. In addition, software will exit to: 

(1) provide a normal computer center jobshop environment when not supporting 
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Table 9.5 J-1. Flight Support and Flight Control Staff Equipment Allocation 
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the real-time IUS mission, and (2) to provide simulation capability in support 
of software development, ground controller training, and procedure verification. 
The principal emphasis within this discussion of the IUS Control Center Software 
will be on the IUS mission support areas of real-time processing and simulation 
activity prior to actual flight. 

The mission support software consists of several interdependent application 
subsystems operating in real-time to satisfy the overall support requirements 
of the control center. The interrelationships of the control center hardware 
and software required to satisfy the support role are shown in Figure 9. 5. 3-1. 

In addition to defining the Control Center functional software specifica- 
tion, the establishment of the overall size of the software is required. This 
sizing information will be later used in costing of software development and 
in establishing the specific central computer size required to support the 
Control Center. Because of costing differences, the software, size will be 
presented in the form of computer words for instruction utilization and those 
used for data allocation. The differentiation between data and instruction 
definitions is shown in Table 9. 5. 3-1. With each of the paragraphs which 
discuss the Control Center software requirements, the corresponding size in- 
formation will be provided. 
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Figure 9.5.3-1. I US Control Center Software Functional interfaces 

Table 9.5.3-1. Instruction/Data Definition 

INSTRUCTION/DATA EXAMPLE 


PROBLEM: Evaluate y as a function of time (t) according to 

the following expression: 

y = A + Bt + Ct^ + Dt^ 

Where: A, B, C, and D are coefficients which determine 

the particular relationship between y and t. 

PROGRAMMING: 

INSTRUCTIONS are the sequence of machine operations 
required to evaluate the expression for y. 

DATA consists of the coefficients A, B, C, and D. 


DISCUSSION: 

Once the instructions for the evaluation have been 
tested, data can be changed without retesting of the 
instruction logic. This reduces the cost of changing 
data words; whereas selection of a new evaluation 
technique will require complete redevelopment. 
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The Control Center mission support software has been subdivided into four 
major functional areas for discussion in this report. These areas are: 

(1) vehicle systems, (2) mission profile, (3) control, and (4) simulation. 

These four subdivisions have been further divided, as shown in Figure 

9. 5. 3- 2, and will be discussed in the order shown. 

9.5.3. 1 Vehicle System Software 

To provide monitoring and control functions, the Control Center is required 
to maintain interface with the I US vehicle through the telemetry downlink 
system and the digital command uplink system. The application software systems 
which provide these interface. capabilities are the downlink processing and 
uplink processing software. These critical subsystems are discussed in the 
following paragraphs. 

9.5.3. 1.1 Downlink Processing 

The downlink processing subsystem processes telemetry data received via' the 
STDN (or TDRSS) from the IUS vehicle. The data is processed in real-time 
and the- results displayed to Flight Control personnel for system evaluation. 

The downlink processing capability is comprised of real-time processing, 
telemetry support processing, and special processing each of which will be 
discussed in subsequent paragraphs. This process is depicted in Figure 

9. 5. 3- 3. Size of the downlink processing software is shown in Table 9. 5. 3-2. 


Table 9.5.3-?. Downlink Processing Summary 
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TOTALS 

82,800 
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Real-Time Telemetry Processing 

The real-time processing capability consists of software to perform decom- 
mutation and conversion of input telemetry parameters utilized in real-time 
support of mission controllers and in performing analysis on telemetry 
parameters to provide system status data regarding the IUS vehicle. This 
process is shown in Figure 9. 5. 3-4. The major processing performed is 
discussed in the following paragraphs. 
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Figure 9.5.3-2. I US Control Center Mission Software Structure 
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Decommutation - The decommutation module of the downlink processor processes 
real-time telemetry data at the input message level. Each message is validated 
for proper sequence by the ground site. Formats of input messages are also 
validated. 

Through the use of a decommutation table, generated offline and loaded upon 
receipt of an input message, the decommutation module will unpack data from 
the input stream into data buffers utilized by telemetry conversion software. 

In addition, information pertaining to the location within the buffer of 
data is provided to user programs. 

Data Conversion - For use within the software subsystems and for display 
to mission controllers and other mission support personnel, the raw input 
telemetry data must be converted into a meaningful format. This function is 
performed by the data conversion modules of the downlink processor through, 
the following steps: 

• Data formatting 

• Check for error conditions and set appropriate status indicators 

• Maintenance of history buffers of input data 

• Perform data conversions 

t Store converted data into appropriate data areas 
■ Limit-sensing of converted data 

Telemetry Support Processing 

The telemetry support processing software is designed to operate in a non-real- 
time environment and is largely dedicted to ‘the data reduction and data analysis 
of all parameters received via the downlink system. The input to the telemetry 
support system is the telemetry history data gathered in real-time and saved on 
auxiliary storage devices for offline analysis. Outputs of the analysis are 
reports for use by flight controllers in evaluating overall system performance. 

Another function performed by the telemetry support software is the generation 
of tables to be utilized for real-time telemetry processing. These tables 
contain the attributes required in processing each telemetered parameter 
and include such characteristics as scaling, calibration information, and 
limits on range. Also included are critical event tables for use in monitor- 
ing correct IUS operation in real-time and display format tables for defining 
console support requirements. 

9. 5. 3. 1.2 Uplink Processing 

Uplink processing involves the formatting and transmission of commands to 
the IUS vehicle via the STDN (or TDRS) and the verification of network 
responses to those commands. The uplink processing software is comprised 
of three major functional areas whose responsibilities are: (1) format and 

transmit all commands; . (2) validate the transmitted commands and update 
command status displays; and (3) perform site and data management. The 
overall functioning of the uplink processing software is discussed in the 
following paragraphs. A functional diagram of the uplink processing is shown 
in Figure 9. 5. 3-5 and the size of the software is shown in Table 9. 5. 3-3. 
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Figure 9.5.3-5. IUS Control Center Uplink Processing 


Table 9. 5. 3-3. Uplink Processing Sizing 


FUNCTION 

NO. OF 

INSTRUCTION 

WORDS 

NO. OF 

DATA 

WORDS 

TOTAL 

SITE MANAGEMENT 

6,800 

13,000 

19,800 

DIGITAL COMMAND PROCESSING 

32,000 

11,400 

43,400 

TOTALS 

38,800 

24,400 

63,200 


P T$* 
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Command Processing Control Program - The command processing control program is 
active' "in' all aspects of uplink processing and performs the following functions: 


• Responds to requests for uplink processing 

• Retrieves and initializes tables 

• Handles communications among program modules utilized in uplink 
processing 

Its overall prime function is to control the operations required in 
response to requests for uplink processing functions. 

Command Generation Program - The command generation program examines the 
input request and determines the command which is required. Using data from 
the command processing data table and data acquired from other ground center 
software, the command is then formatted for transmission. Prior to trans- 
mission, appropriate display tables are updated for mission controller 
verification of correct command format. The command is then 'transmitted to 
the appropriate remote site ground station for uplink to the IUS vehicle. 

Command Validation Program - All commands transmitted to remote sites are 
1 echoed 1 back to the ground control center with status information indicating 
whether the command was accepted or not. In addition, the command validation 
program has .a “time-out" feature in the event that no response is obtained 
from the remote site within the specified interval. 

The command validation program processes the ‘echo 1 messages and will print 
messages for those commands flagged as invalid. These print message will 
indicate the command as well as the reason for invalidity. Command messages 
successfully received by remote sites and verified are logged into command 
history tables. 

Site and Data Management - The site and data management program updates the 
command- related displays for use by mission controllers. The displays are 
only updated upon request for command processing and contain the following 
types of information: 

• Site management command history 

• Overall command history 

• Critical parameter changes executed through the uplink system 

• Failure analysis history 

9. 5. 3. 2 Mission Profile Software 

The mission profile software of the ground control center is primarily con- 
cerned with trajectory-associated functions. The functional requirements 
satisfied within the mission profile software are listed below and are 
discussed in more detail in subsequent paragraphs. 

• Orbit trajectory determination 

• Orbit trajectory computations 


9-36 



The overall estimated size of the mission profile software is shown in 
Table 9. 5. 3-4. In addition, major subdivisions of the software are shown. 


Table 9J5.3-4. Mission Profile Software Sizing 


FUNCTION 

NO. OF 

INSTRUCTION 

WORDS 

NO. OF 

DATA 

WORDS 

TOTAL 

TRAJECTORY DETERMINATION 

63,500 

62,300 

125,800 

LOW-SPEED RADAR PROCESSING 

17,700 

8,000 

25,700 

HIGH-SPEED RADAR PROCESSING 

4,600 

1,000 

5,600 

ORBIT TRAJECTORY COMPUTATIONS 




EPHEMERIS GENERATION AND 




CONTROL 

24,000 

5,500 

29,500 

MANEUVER COMPUTATIONS 




AND CONTROL 

21,500 

1,200 

22,700 

STATION CONTACTS 

10,800 

1,000 

11,800 

TOTALS 

142,100 

79,000 

221,100 


9. 5. 3. 2.1 Orbit Trajectory Determination 

In maintaining current trajectory information on the IUS vehicle, two types 
of radar input measurements are utilized. High-speed radar input measure- 
ments are utilized during mainstage burn phases, and low-speed radar 
measurements are received from remote radar tracking stations, batched, 
edited, and processed within the orbit trajectory determination software to 
provide refined IUS state vectors for use in orbital trajectory computations. 
A functional, diagram of the orbit trajectory determination software is shown 
in Figure 9. 5. 3-6. 

High-Speed Radar Processing 

The high-speed radar input processing is used during mainstage burn phases 
and provides the ability to display the vehicle trajectory status in near- 
real -time. The high-speed input processor utilizes radar inputs transmitted 
from remote radar sites or range and range rate data transmitted thru TDRS. 
Each message rceived will be tested against a prescribed set of error limits 
before being accepted for subsequent processing. 


9-37 




© o 

*0 q? 

Sg 


RADAR PROCESSING 

HIGH LOW 

SPEED SPEED 

RADAR RADAR 


VECTOR CONTROL 
AND EVALUATIONS 


VECTOR EVALUATION 
MED INPUT. 


ANTENNA 

MANAGEMENT 


HIG H SPEED DATA LOW SPEED 

1 INPUT COLLECTION INPUT 


LOW SPEED 
INPUT DATA J 


MISSION 
PLAN 
TABLE _ 


VECTOR 

CONTROL 


EPHEMERIS 

TABLE 


COMPUTE 

LOOK 

ANGLES 


INPUT 

MED 


C ^ 


» ... _ . . 

VECTOR INTEGRATION 

VALIDATION 

INPUT SPECIFYING — 
STATION DATA 

RADAR INPUT 
_ PROCESSOR 

UPDATED 

VECTORS 


TO SPECIFIED CRITERIA 


DISPLAY TO 
CONTROLLER 


COMPUTE 

TRAJECTORY 

DATA 


DISPLAY FOR 
SELECTION OF- 
PROPER DATA 


INPUT 

SATISFYING 

SPECIFIED 

CONSTRAINTS 


COMPUTE ORBITAL 

ELEMENTS 

FOR ALL VECTORS 


ORBITAL 

ELEMENTS 

DISPLAY 

TABLE 


EVALUATION BY FLIGHT 
CONTROLLER VIA DISPLAY 


DISPLAY 

DATA 

TABLES 


PLOTBOARDS, 
CONSOLES, ETC. 


LOW SPEED 
RADAR INPUT 
PROCESSOR 


STORE SELECTED 
VECTOR FOR 
EPHEMERIS UPDATE 


MED INPUT 
SPECIFYING VECTOR 
' SELECTION FOR 
EPHEMERIS UPDATE 


DISPLAY 

EVALUATION 


ANCHOR 

VECTOR 

TABLE 


^ 


+ 


CL * 

EXTERNAL 

DATA 

TABLE 


DIFFERENTIAL 

CORRECTION 

PROCESS 


UPDATED 
VECTORS AND 
COVARIANCE 
.MATRICES 


Figure 9.5.3-B. Orbit Trajectory Determination 
















The high-speed processing software will execute at a rate of twice per 
second and will provide the following parameters for display: 

• IUS vehicle velocity 

• IUS vehicle altitude 

• IUS vehicle flight path angle 

• Latitude of present position 

• Longitude of present position 

Low-Speed Radar Processing 

Since the coast phases of the mission consititue the majority of the mission 
timeline and the environment is more predictable, the majority of orbit 
trajectory determination calculations are performed on low-speed radar inputs. 
The software elements required to satisfy the processing of low-speed radar 
inputs are discussed in the following paragraphs. 

Data Collection - The data collection processor is responsible for receiving, 
retaining, or discarding of low-speed radar inputs. Input data .is routed to 
the real-time input program for validity and quality testing. Control over 
validity and quality testing is provided through manual entry devices. 

Radar Input Processor - The function of the radar input processor is to read, 
from a defined tape drive, low-speed radar data within specified time limits 
and pass the data to low-speed radar input processor for possible inclusion 
in data batches. 

The input processor is under control of manual entry devices. The processing 
is initiated after specifying the tape drive, start time, end time, operating 
priority, and stations from which data are to be retrieved. A history tape 
is read until the begin time is found. The data is then checked against 
data type and transmitting station. Acceptable data is collected and passed 
to the low-speed data input processor. 

Low-Speed Radar Input Processor - The function of the low-speed radar input 
processor is to form batches of data, according to radar station and vehicle, 
for possible differential correction (DC) computations. Data is. routed based 
on validi.ty/quality checks and batch requirements. 

The following types of quality checks are performed on input data: 

• Each teletype character and total message length must be 
valid. 

• Data frame must contain frame identification character. 

• Message must be from valid station. 

• Elevation angle must be greater than or equal to the 
acceptable minimum. 

e Time difference between observations must be greater 
than or equal to a minimum specified via manual entry 
device. 

• Quality indicators set by remote sites must be set to 
‘GOOD 1 . 
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• Range and angle data must be within specified limits. 

Failure to pass these tests will result in the input being discarded; whereas, 
acceptance will result in the input being passed for further processing. 

Prior to differential correction processing, all low-speed batched radar 

data are retained in the low-speed collection table and formatted for evaluation 

and viewing by the appropriate mission controller. 

Differential Correction - The differential correction (DC) process uses 
low-speed radar data, an initial estimate of the state vector, and an initial 
covariance. DC is performed thru the execution of the following programs. 

DC Control - The DC control programs contain the logic required-to perform 
the following basic steps: 

• Select the DC inputs, which include the radar data to be 
used, the input vector, the input covariance matrix, and 
the appropriate K- factor. 

• Control the propagation function, which consists of 
integrating the input vector and propagating the co- 
variance matrix to the start time. 

t Present the result of the DC to the user in the form of 
di spl ays . 

DC Propagation - This process requires that the input vector and covariance 
be updated to the time of the first observation in the set of data upon 
which a correction is to be performed. The DC propagation program provides 
the capability of integrating the input vector and propagating the covariance 
matrix to the desired time. Integration and propagation through both non- 
powered maneuvers is provided. 

DC Convergence - The inputs to the convergence program are a list of up to 
80 input batches with an initial estimate of the state vector and covariance 
matrix. The convergence processor is the basis of the DC function, containing 
the logic and mathematical formulation necessary to compute the updated 
state vector and associated covariance matrix. 

To accomplish DC convergence, the following steps are executed: 

• For each observation, compute its residual, weight, and 
partial with respect to the current state vector. 

• Solve the equations for the vector correction, update 
covariance, and bias terms. 

« Calculate the new vector and bias estimate by adding the 
corrections computed above. 
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Vector Control and Evaluation 


The function of the vector control and evaluation software is to provide the 
flight controller the capability to compare the current IUS vehicle trajectory 
data with those predicted previously and, if required, to select a new anchor 
vector for ephermeris generation. The vector control and evaluation software 
is under complete control of the mission controller and will be executed only 
upon receipt of a manual entry device (MED) request. 

The vector control portion of the software collects specified vectors from 
the current ephemeris table and updated vectors from the radar processing 
software and places them into data tables for subsequent processing. In 
addition, the MED input data is also placed into the data tables. 

The vector evaluation portion of the software integrated all vectors to the 
conditions specified via the MED input and computes the display data for use 
in the evaluation process. If a new anchor vector is required for subsequent 
ephemeris generation calculations, the new vector is placed into the anchor 
vector table. 

9. 5. 3. 2. 2 Orbit Trajectory Computations 

The orbit trajectory computations software is responsible for generation 
of current trajectory information. In particular, it: 

• Maintains current orbital ephemerides which describe IUS vehicle 
trajectory containing periods of free-flight and/or powered 
flight. 

• Maintains detailed information for currently planned maneuvers. 

• Computes and formats information relevant to radar station 
time and duration of track for transmission to the tracking 
network. 

• Computes numerous parameters for definition and evaluation of 
predicted IUS trajectories. 

The software to accomplish the above functions is discussed in the following 
paragraphs. A functional description of the trajectory computation process 
is shown in Figure 9.5. 3-7. 

Ephemeris Generation and Control 


The ephemeris generation and control software generates, maintains, and 
references ephemerides for the IUS vehicle, the Space Shuttle, and the 
target vehicle. The ephemerides provide rapid access and/or computation 
of tracjectory dependent data for mission planning and real-time flight 
monitoring. 

The ephemerides are of two types, live or static. A "LIVE" ephemeris des- 
cribes the current trajectory of a vehicle. ■ It is considered live because the 
trajectory is computed and output on trajectory evaluation displays for 
monitoring purposes.. In addition, the live ephemeris is advanced as current 
time processes. A "STATIC" ephemeris describes the predicted trajectory from 
an anchor vector whose time is anywhere within the mission profile. The 
anchor vector is either specified by the user or defaults to the times of the 
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Figure 9.S.3-7. Trajectory Computation Process 


last anchor vector specified. The "STATIC" ephemeris, therefore, does not 
advance with time but instead remains fixed at the defined base state. 

Ephemerides have the following additional characteristics: 

t -Each can contain periods of free flight and/or powered 
flight. 

• Density of each ephemeris is three minutes for free flight 
periods and 10 seconds of powered flight periods. 

The ephemeris generation and control software is subdivided into three 
major areas:' (1) control logic, (2) ephemeris generation logic, and 

(3) display requirements. These areas are addressed in the following para- 
graphs. 

Control Logic - The control logic performs initialization and superr 
visory functions necessary in maintaining and referencing vehicle ephemerides. 
There are five categories of processing within the control logic: (1) 

input processing, (2) anchor vector table maintenance, (3) vector routines, 

(4) trajectory update supervision, and (5) miscellaneous vector processing. 

The following steps are executed in performing these functions: 

• Vector for a specified vehicle ephemeris is entered via 
manual entry device. 
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• Vector is stored in anchor vector table, 

t Ephemeris vector is generated. 

• A trajectory update is performed utilizing new anchor 
vector. 

• Miscellaneous vector routines are used to perform trajectory 
computations. 

Ephemeris Generation - The ephemeris generation software' performs the actual 
generation of a vehicle ephemeris and updates the necessary tables to reflect 
the current trajectory. Since each ephemeris can contain periods of free- 
flight and powered flight, the software updates the ephemeris table with 
both types of vectors. 

Display Requirements - This portion of the ephemeris generation and control 
software provides the capability to display ephemeris associated data to 
flight controller personnel. These displays contain the following types 
of data: 

• Vehicle state vector at specified time 

• Earth-referenced position at specified time 

• Arrival time and orientation at specified point 

• Current vehicle state vector 

• Time-to-go to specified position 


Maneuver Computations and Control 

The maneuver computations and control software are responsible for processing 
inputs related to the computation and insertion of maneuvers into the appro- 
priate vehicle ephemeris and inputs related to all trajectory updates that 
involve maneuvers. The primary function of this software is to control the 
generation and maintenance of maneuver information in the mission planning 
table. To accomplish these functions, the maneuver computations and control 
software are comprised of three' subsystems - control logic, maneuver definition 
unit, and display requirements. 

Control Logic Unit - The control logic supervises the processing of inputs 
that affect and/or update the mission plan table for a specified vehicle • 
ephemeris. The primary function of this processing is to guarantee the 
accuracy and consistency of maneuver definitions in the mission planning 
table. The following functions are performed by the software: 

• Input processing 

• Maneuver update to the mission planning table due to a 
maneuver definition 

• Freeze, unfreeze, deletion of a maneuver being input and 
changed 
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• Change weights, areas, fuels, K- factor, and/or initial 
configuration codes 

• Execute a maneuver in the mission planning table 

Maneuver Definition Unit - The purpose of this program is to process and/or 
compute the maneuver targets which properly define a desired finite burn 
in the mission plan table. 

There are two ways in which maneuvers can be defined. The desired finite 
burn targets plus ignition time can be specified, or an impulsive maneuver 
time plus the specified orbits before and after the burn can be specified. 

Overall, the maneuver definition unit is responsible for generating or 
accumulating all data which must be stored into the mission planning table. 
The types of maneuvers supported for the IUS vehicle are: 

• .-Mainstage burn maneuvers 

t Midcourse -AV maneuver 

• Venting maneuvers 

• Non-propul si ve maneuvers 

Display Requirements - The purpose of the maneuver display software is to 
provide maneuver- associated data for use in display to flight controllers. 
For each maneuver, the following data will be provided: 


• GMT of maneuver initiation 

• Incremental velocity required to accomplish maneuver 

• Height of apogee after maneuver 

• Height of perigee after maneuver 

In addition, maneuver information for evaluation by flight controllers will 
be provided. Example of this data are: 

• .Maneuver definition and targetting parameters 

• Maneuver execution parameters 

• Resultant trajectory information ' 

• Maneuver update information 

Station Contacts 


The station contacts software determines when the IUS vehicle and radar 
ground stations are in contact with each other, displays this data, and 
informs the remote station of upcoming contact periods. To accomplish 
these functions, the software has been divided into the following areas: 

• Station contact generation 

• Station contact displays 

• Remote site acquisition 
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Station Contact Generation - The programs in this unit generate orbit station 
contact information based on specified ephemeris. The mathematical models 
required to determine horizon crossing times, terrain masking effects, and 
keyhole loss of signal times are maintained. When given site definitions and 
ephemeris data, the program will generate a chronological list of station 
contacts . 

Station Contact Displays - The station contact displays software produces 
information about present and future station acquisition and parameters 
associated with those contacts. 

Remote Site Acquisition - The transmission of acquisition messages to the re- 
mote tracking stations is the function of this software. Information contained 
within the messages is as follows: 

• Slant range, receiver frequency, transmitter frequency, 
bias doppler, and one way doppler to S-Band stations 

• Pointing data for tropospheric refraction 
9. 5.3.3 Control Software 

The Control Software provides the capabilities to control overall software 
execution and interface with Flight Support Facilities. A diagram of the 
functioning of the Control Software is shown in Figure 9. 5. 3-8. 



Figure 9.5.3-8. I US Control Center Control Software 
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9. 5. 3. 3.1 Executive 


The executive program functions as the supervisor of the application software 
within the central computer and controls and sequences all input/output 
activity. In addition, the software within the executive will provide the 
capability to recover from component failures within the control center 
without degrading system integrity. The subelements which comprise the 
executive and the size of the executive software are shown in Table 9. 5. 3-5. 


Table 9.5.3-S. Executive Software Summary 


FUNCTION 

NO. OF 

INSTRUCTION 

WORDS 

NO. OF 

DATA 

WORDS 

•TOTAL 

TASK MANAGEMENT 

78,600 

6,100 

84,700 

APPLICATION TASK CONTROL 
INITIALIZATION 
ERROR RECOVERY 
QUEUE MANAGEMENT 
MASTER SCHEDULER 
OPERATING SYSTEM UTILITIES 


\ 


DATA MANAGEMENT 

78,600 

8,600 

87,200 

RESOURCE MANAGEMENT 
DATA LOGGING 
STATISTICS GATHERING 
AUXILIARY STORAGE 
OPERATING SYSTEM UTILITIES 




INPUT/OUTPUT MANAGEMENT 

31,800 

5,100 

36,900 

I/O CONTROL 
INTERRUPT HANDLING 
OPERATING SYSTEM UTILITIES 

- 



SYSTEM INITIALIZATION 

33,000 

13,500 

46,500 

TOTALS 

222,000 

33,300 

255,300 


The executive program is designed to: 

• Minimize the application system hardware dependence 

• Ensure fast response to system activity 

• Provide simplicity to application program development 

• Provide the support to application software in handling 
large amounts of real-time data 
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r Provide a flexible base for future expansion 

The major functions provided for application software are task management, 
data management, input/output management, system initialization and simu- 
lation support. These major functions are discussed in the following 
paragraphs. Reference should be made to Figure 9. 5. 3-8 to follow the 
interfacing of the subelements discussed following. 

Task Management 

The task management capability of the executive is built upon the independent 
task concept. In this concept, an independent task is able to receive work 
at all times regardless of the input data rate. When data is received by the 
system for a task, i-t is sent in the form of a request. Each request has 
its own priority which in turn becomes the priority of the task. If a task 
is processing a request and a new request is received from the task, the new 
request is held according to its priority and processed upon completion of 
the request in progress. 

Each task is assigned an area in main storage called a resource table. This 
is a private area that can be used by the program running under the task. In 
addition, each task is assigned a unique protect key which protects it from 
all programs controlled by other tasks. 

Master Scheduler - The master scheduler examines all input data and acts 
as an interface between the hardware interrupt servicing function and the 
task management function. When the master scheduler receives an input 
message, it compares the message with the current data definitions. If a 
compare exists, the message is routed to the task which will process it. If 
no compare exists, the message is discarded. The master scheduler can also 
accumulate a number of messages for the same task and generate a request for 
the task after the specified number of messages have been received. In this 
case, all the accumulated messages will be sent to the task as one request. 

Within the Control Center, work requests will also be generated according to 
elapsed time. For example, a task may be created to control a load module 
which updates the position of the vehicle every second. The only data 
necessary to perform this operation is the previous position and the orbital 
parameters. Since this data exists within the software system, no external 
signal will occur to request execution of the task. In a case such as this, 
the request will be generated through a timer interrupt under control of the 
software. .This technique for task requests is known as time routing. 

Time Routing - Time routing is used within the Control Center software to 
generate work requests on specified time intervals. It functions as the 
interface between the time management function of the executive and the task 
management function. When an application program requests a series of time 
dependent activations, the time routing program sends the request to time 
managment specifying the time when the next request should be generated. 

When the timer interrupt associated with the request is received, time manage- 
ment will call the time routing function which, in turn, will call the 
required task. 
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Queue Manaqement - As mentioned previously, if a task is processing a work 
request, all other requests for that task must be held by the system until 
the task is available for further processing. To support this operation, 
the executive must build and maintain a queue of work requests waiting to 
be processed by each active task. Information concerning each request is 
held in a real-time queue element. 

Each active task will be processing one work request and that request is 
represented by the active queue element. All other requests for the tasks 
will be placed in the queue of ‘waiting' elements. Requests from the 
'waiting' elements are ordered according to priority; in the case of equal 
priority, first-in first-out (FIFO) is the order of processing. When the 
task completes, the request of high priority is made active and passed to 
the task for processing. If no 'waiting' requests exist, the task becomes 
dormant awaiting new data for processing. 

If queue management is not provided, the queue elements can accumulate 
indefinitely unless the tasks can process their work requests faster than 
they are generated. Queue management provides the capability to control 
requests by limiting their number. It can also be used to control system 
load by not giving requests to a task’ until other tasks are complete. 

Time Manaqement - The computer to be utilized within the IUS Control Center 
will be equipped with a special high resolution GMT clock and interval timer. 
To provide support for these timer devices, a time management supervisor will 
be required within the executive. The supervisor maintains system time and 
controls the setting and interrupt handling functions resulting from the 
timer hardware. 

System Recovery - It is of prime importance that the software continue to 
function in the presence of errors or failure conditions. Three areas of 
software are required to address: switchover, high-speed restart, and 
error recovery. 

For system reliability considerations, a backup main computer system will 
exist within the ground control center. The ability to select the backup 
computer system without interruption to the input/output processing. of . 
rea 1_time data or degradation of mission output will be performed within 
the executive program. 

In the event of computer failure, the backup computer system must be brought 
online within a minimum specified time interval. An initial load program will 
exist within the executive to transfer all required data from the operational 
system to the selected backup system. 

The error recovery function of the executive pertains to errors resulting 
from program checks, hardware malfunctions, or abnormal conditions arising 
within the software system itself. In effect, error recovery capability is 
restricted to those errors recognizable within the software for which software 
action can be taken. The error recovery programs will print appropriate 
messages and recommendations regarding system status. 
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Operating System Utilities - The executive program for the IUS Control Center 
will be built around the capabilities of the operating system provided with 
the computer. This approach will allow utilization of existing system soft- 
ware and will provide a standard base for development of application software. 
In addition, the utilization of the computer's operating system will allow 
one control center computer to be used for normal job processing when not 
being used for real-time mission support. 

Input/Output Management 

Because of the real-time nature of input/output processing, special techniques 
must be provided to handle this activity efficiently and rapidly. These 
techniques are included in the following functional areas of the input/output 
management software: 

• Real-time access method 

• Real-time interrupt servicer and start-stop input routing 

• Digital/TV display control 

• Shared device support 

Real-Time Access Method - The real-time access method performs device dependent 
data manipulation and output messages to special real-time devices within the 
IUS Control Center. It also is used to control the reading of information from 
the display hardware used by flight controllers. Output to all display hard- 
ware is also controlled by the real-time access method. 

Real-Time Interrupt Servicer and Start/Stop Input - The real-time interrupt' 
servicer and start/stop routines provide control over the input from real-time 
input devices within the control center. The servicer passes the request 
information to the master scheduler for use in scheduling the execution of the 
appropriate task. The start/stop input routine controls the initiation and 
transfer of data from the input device and can stop the transfer in the event 
‘of failure. 

Digital Display Device Control - The digital display device control software 
centralizes and simplifies the control of digital displays. The control 
program is entered when user request-change in display information. The 
control routine updates the display format and passes the new data to the 
real-time access method for output. 

Shared Device Support - The shared device support program acts as an inter- 
face for computer jobs which may share devices. Inputs for use of shared 
devices are received and routed to the appropriate task; outputs to the 
shared devices are controlled through this program. 

Data Management 

The data management portion of the ground control center executive performs 
the functions of: 

9 Data logging 

• Data table maintenance 

• Auxiliary storage control 

• Background utilities 

The functional discussions of these elements are contained in the following 
paragraphs. 
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Data Logging - In a real-time environment, it is essential that a technique 
be provided which saves the data received, transmitted, and processed by the 
system. Within the control center, all such data is recorded on magnetic 
tape. In addition to system inputs/outputs, application program data can be 
recorded for program checkout purposes. 

Data Table Maintenance - Because of the large amounts of data which must be 
accessed and manipulated during support of an IUS mission, a series of control 
programs will be utilized to support data table handling. 

Data tables are blocks or arrays of data maintained on direct access devices. 
Through use of data table control software, tables can be ’logged' to ensure 
data integrity and consistency during a read operation. This will delay any 
tasks attempting to write into the table until the data has been 'unlocked'. 

Each data table is identified by a name field and is defined by its block 
size and number of blocks. A data table generation program uses these 
parameters in allocating space for each table and providing the controls 
required to access it. 

Auxiliary Storage Control - Because the overall software size for the control 
center will exceed the capacity of the computer's main memory, direct access 
devices will be used to store all programs not required to reside in memory 
at all times. The retrieval of these programs from auxiliary storage in real- 
time and the dynamic loading into main memory are functions performed by the 
auxuiliary storage control software. 

Background Utilities - Numerous capabilities have been included in the 
executive for use in background operations which can be initiated or terminated 
by console operation. These background utilities execute asynchronously with 
normal operation and provide the following capabilities: 

• Dump auxiliary memory to tape 

• Restore auxiliary memory from tape 

• Clear auxiliary storage device 

• Copy a tape 

• Compare tapes 

• Print magnetic tape 

Statistics Gathering System - The statistics gathering system provides timing 
information and execution frequency statistics useful in accessing overall 
system performance. Example of the types of statistics are given below: 

• CPU Performance - shows the amount of CPU utilization, 
the time spent waiting on I/O, or time spent in gathering 
statistics 

• Load Module Performance - shows the execution frequency, 
average execution time, percent of CPU utilization, and 
number of requests for each task 

• Task Performance - shows the number of task executions 
per specified time interval and the execution time for 
task 
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• Executive Performance - shows the percent of CPU utilization 
spent in performing executive functions 

System Initialization 

Prior to initiation of the application software to support an IUS mission, 
the executive will perform the necessary diagnostics on system hardware, 
configure the hardware in accordance with input specification, and initialize 
the application software to accept task requests. 

The system initialization software will reside on auxiliary storage devices 
and will be loaded into main memory under control of the computer's operating 
system. The initialization software then controls the loading of remaining 
software into main memory and will pass control to the task management 
function when all initialization tasks have been completed. The main memory 
utilized by system initialization then becomes available for system use. 

Simulation Support 

To assist in development of the application software, the executive program 
has two features which provide significant testing capability. These features, 
discussed below, are simulated input control (SIC) and fast time. 

Fast Time - -Fast time is a capability of the executive to stop the time 
reference if no software activity is scheduled. In this way, many hours of 
computer time and programmer time can be saved. Using this capability, the 
input messages are processed as rapidly as the tasks can be run. 

Simulated Input Control (SIC) - Simulated input control provides the cap- 
ability to send simulated input data into the application software for test 
purposes. This input data can be in the form of cards or tape or both. All 
data has the time of receipt associated .with each message and SIC routes 
each data message to the master scheduler for scheduling of the required task. 
For convenience, SIC will allow data log magnetic tapes to be used as source 
for simulated input. In this manner, actual data obtained from previous 
flights or simulations can be used as a test bed for software change veri- 
fication. 

9. 5. 3. 3. 2 Control Center Support Software 

As was discussed .previously, the executive program provides the input/output 
capability to interface with the hardware devices within the control center. 

In addition to the software existing for input/output, significant software 
is required to format data properly for output, to provide the data requested, 
and to maintain the data base required for display purposes. A functional 
description of the control center support software's relationship to the 
executive and hardware external to the computer system is shown in Figure 
9. 5. 3-8. Sizing data is shown in Table 9. 5. 3-6. 
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Table 9. 5.3-6. Control Room/Display Management 


FUNCTION 

NO. OF 

INSTRUCTION 

WORDS 

NO. OF 
•DATA 
WORDS 

TOTAL 

DISPLAY DEVICE INPUT SERVICING 

3,800 

400 ■ 

4,200 

DISPLAY DEVICE OUTPUT 

10,000 

4,800 

14,800 

TOTALS 

13,800 

5,200 

19,000 


9. 5.3.4 Simulation System Software 


In the development and qualification of the control center, data from external 
sources such as remote sites, IUS vehicle, etc., will not be available on a 
continuing basis. In addition, certain hardware systems wi'thin the control 
center may not be available when needed to support testing. To provide an 
environment to assure the capability to perform testing at all times, deve- 
lopment of a simulation capability will be required. This simulation cap- 
ability will be performed through software modelling of the control center 
environment. The simulator will provide simulated real-time inputs, under 
control of simulation personnel, to test both the nominal and contingency 
capabilities of the control center. 

Simulations have been utilized in both the Mission Control Room at JSC and 
at the Deep-Space Control Center at JPL with significant results. For the 
IUS Control Center, the simulation system will be used to address testing 
requirements associated with hardware checkout, software development, pro- 
cedural verification, and ground controller training. 

The subelements which comprise the simulation system are shown, with 
corresponding sizing information, in Table 9. 5. 3-7. 


Table 9. 5.3-7. Simulation System Size 


FUNCTION 

NO. OF • 

INSTRUCTION 

WORDS 

m 

TOTAL 

IUS VEHICLE SIMULATION 

43,200 

12,700 

55,900 

GROUND STATION SIMULATION 

55,000 

12,500 

67,500 

CONTROL CENTER SUBSYSTEMS 




SIMULATION 




DISPLAYS 

11,500 

16,900 

28,400 

MED ENTRIES 

15,000 

9,000 

24,000 

SIMULATED INPUT CONTROL 

7,500 

11,300 

18,800 

TOTALS 

132,200 

62,400 

194,600 
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9. 5. 3. 4.1 Simulation Description/Operation 

The overall functional description of the simulation system and its re- 
lationships with the operational software and hardware of the control center 
are shown in Figure 9. 5. 3-9. The simulation system contains models of the 
following operational components: 

e IUS vehicle 

® Ground station 

e Rada'r tracking sites 

• Subsystems with'in the control center, such as displays, 

consoles, and panels 

To provide a near real-time environment, the simulation system software will 
be executed within the backup central computer system. The primary central 
computer will contain the operational software of the control center. The 
simulation software will perform all modelling, as requested by the simu- 
lation controller, and provide inputs to the operational software. Outputs 
of the operational software will be directed to the control center hardware 
or simulated models. Uplink commands will be routed to the simulation system 
rather than to remote sites. Through this operation, a closed-loop simulation 
is achieved which will provide significant flexibility in the overall testing 
plan for the control center. 

The elements of the simulation system are discussed in the following para- 
graphs . 

IUS Vehicle Model - The model of the IUS vehicle is a detailed mathematical 
model which includes. the following onboard systems: 

• Onboard computer (includes onboard computer software) 

• Guidance 

t Telemetry 

• Stabilization and control 

• Reaction control 

■ Propulsion 

• Sequential events 

• Atti tude sensors 

• Upl i nk command 

• Power 

t Payload 

Ground Station Model - The ground station model will accept as input the 
telemetry data generated by the veicle module and will generate telemetry 
data in the format acceptable to the IUS Control Center software. 

Radar Tracking Station - A simulated vehicle trajectory will be used to 
generate low-speed and high-speed radar input data for use in the control 
center's operational software. The trajectory will be updateable during 
the simulation to provide off-nominal IUS vehicle perturbations. 
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Control Center Hardware - Since a signficant portion of the simulation will 
be controlled from flight consoles and manual entry device inputs, this 
control center hardware will be modelled within the simulation system. 

For MED inputs, tables of input data to be executed as a function of mission 
time will be established prior to the mission simulation. As the mission is 
simulated, these inputs will be issued at the appropriate time. Each issu- 
ance will be -logged for post-simulation analysis, and, in addition, tests 
will be conducted, during the simulation, on response of the operational 
software to the stimuli issued through the MED simulation. 

Display simulation will test the capability of the operational software to 
properly respond to display requests and display properly formatted data. 

The display data will be logged for post-simulation analysis. Correlation 
between the data generated by the simulation and that calculated and 
displayed will be accomplished during the simulation and logged for analysis, 

Simulated Input Control - The simulated input control, although a subset 
of the simulation system, is a ‘stand alone' simulation tool for selective 
entry of data into the operational software. This capability provides a 
means of performing software checkout without the overall simulation system 
being involved. The input is largely manual and provides a tightly control!! 
testing environment. 

9 . 5 . 3 . 4. 2 Simulation System Utilization 

As was stated previously, the prime uses of the simulation system are: 

c Hardware checkout 

• Software development 

• Procedural verification 

• Flight controller training 

Hardware Checkout - Through use of the hardware simulation capability, a dat 
base can be provided for comparison between actual hardware and modeling tes 
cases. Replacing software models with actual hardware also provides veri- 
fication of system interfaces prior to overall system testing. 

Software Development - The simulation system will be utilized to provide 
inputs, during software development, for program checkout purposes. Because 
of the input control features of the simulation system, predictable test 
cases can be generated and conducted. This use of the simulation system wil 
provide a base for systematically testing the operational software in a real 
tic environment and will allow testing to proceed at the overall system leve 
before requiring the participation of outside activities. 

Procedure Verification - Prior to each IUS mission, a flight plan will be 
generated. This flight plan will detail the procedures to be foil owed to en 
that the IUS mission achieves all objectives. The simulation system will pr 
vide the test bed to verify that the procedures are correct-. 
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Flight Controller Training - Flight controllers must be trained to. handle 
all contingency situations. In view of the criticality of flight controller 
expertise, a thorough training program prior to the actual mission must be 
provided. 

The simulation system is ideally suited to provide the training needed by 
flight controllers. The simulation system in conjunction with the control 
center software can reproduce all nominal events and non-nominal conting- 
encies which may occur during a mission. The active participation -of flight 
controllers in overall system simulation will ensure that the controller is 
thoroughly familiar with available mission support tools, data and will 
provide training in a real-time environment. 

9. 5. 3. 5 Software Summary 

This section of the I US study report has identified the functional software 
requirements which must be satisfied in order to control the IUS vehicle 
from a control center. The overall size of the software has also been 
addressed and is summarized in Table 9. 5. 3-8. 

The primary emphasis has been placed on ensuring that all the functional require- 
ments have been addressed. The software' size, which has been developed, is 
based on a study of similar software at the JSC-RTCC and JPL-DSC. As can be 
seen in Figure 9.5.3-10, the IUS software size is less than previous ground 
control center software for other space programs; however, as the IUS control 
center requirements are more clearly defined, the software may grow. 


Table 9.5.34. IUS Control Center Software Summary Size 


FUNCTION 

NO. OF 

INSTRUCTION 

WORDS 

NO. OF 

DATA 

WORDS 

TOTAL 

DOWNLINK PROCESSING 

82,800 

21,900 

105,700 

UPLINK PROCESSING 

38,800 

24,400 

63,200 

MISSION PROFILE 

142,100 

79,000 

221,100 

EXECUTIVE SYSTEM 

222,000 

33,300 

255,300 

CONTROL CENTER SUPPORT 

13,800 

5,200 

19,000 

DATA COMMUNICATIONS 

3,800 

2,500 

6,300 

SIMULATION SYSTEM 

132,200 

62,400 

194,600 

TOTALS 

635,500 

228,700 

865,200 
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Figure 9.5.3-10. Space Programs Mission Software Size 


9.5.4 AIRBORNE OPERATIONS SUPPORT SOFTWARE 

The Flight Software requirements for a Level B EIUS vehicle are estimated, based 
upon the anticipated share of the mission operations decision requirements. 

Four baseline flight programs have been postulated, and the specific mission 
implementation is to be a modular adaptation of one of the baseline programs. 

The following paragraphs discuss the general approach to the IUS Flight Program. 

The flight program is an integral part of: (1) the guidance and control sys- 

tem comprising the central computer, I MU and the flight control electronics; 
and (2) the IUS sequencing system comprising the discrete input, discrete out- 
put, and interrupt processing of the central computer. 

The integration of these systems is accomplished through the flight program. 

It provides a flexible mechanism by which the system functional and detailed 
specifications may be altered, within wide limits, to accomplish a wide variety 
of missions without changes to the vehicle hardware. 

Although specific requirements will vary with mission phase, the flight pro- 
gram is required to provide for the following recurring functions. 

• Navigation 

• Guidance 

• Attitude Control 

o Sequencing 
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• Telemetry 

• Programmed backups to specific hardware functions 

• Command processing 

• IMU processing 

9.5.4.1 Non-Recurring Functions 

The one-time targeting requirement is performed at approximately two hours 
prior to shuttle liftoff. The targeting parameters are loaded via the LPS 
with a backup load performed by ground DCS command if required. 

9. 5.4.2 Recurring Functions 

Of the recurring functions listed above, command processing is required for the 
one-time targeting requirement and during the orbital mission phase. The re- 
maining functions are required during both the boost and coast phases although 
specific requirements and rates of computation may vary from the boost to the 
coast phases. Each requirement is discussed separately except for navigation 
and guidance which are more closely tied together than the other requirements. 
In addition, the guidance law and navigation scheme requirements are signifi- 
cantly different during the boost and coast phases. Therefore, these two re- 
requirements are combined in the discussion and this particular discussion is 
broken into boost and coast mission phases. 

The following definitions of navigation, guidance and control apply in this 
document. 

Navigation: The calculation of vehicle position 

and velocity at any time with respect 
to a specified reference frame. 

Guidance: The computation, according to a specified 

law, of instantaneous vehicle attitude, 
with respect to a specified reference 
frame, necessary to achieve a specified 
state vector and/or vehicle attitude at 
some future time. 

9. 5. 4. 2.1 Boost Navigation and Guidance 

Since variations in acceleration are large during boost, the computation rate 
for navigation must be higher than during coast. In determining position and 
velocity relative to the desired reference frame, gravitational effects are 
computed as part of the navigation scheme since the sensors cannot measure 
gravitational acceleration. A mathematical model of the earth's gravitational 
field, which was empirically derived from satellite measurements, will be used 
in the gravitational computations. Position and velocity in the desired ref- 
erence frame are obtained by differencing the integrated measured and gravi- 
tational accelerations. The computation rate, or integration interval will be 
variable. With these rates, and the smoothed acceleration function, a simple 
trapezoidal integration routine yields sufficient accuracy. A single naviga- 
tion scheme is adequate through the boost phase. 
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In order to achieve the correct orbital inclination and longitude of’ descend- 
ing node, active guidance is required in both the pitch and yaw planes. Com- 
pensation in the guidance law is required for abrupt transients in vehicle 
performance and for subtle off-nominal vehicle characteristics such as center 
of gravity offsets. In general, active guidance laws, including IGM, tend to 
become unstable as the end conditions are approached. In order to maintain a 
stable vehicle at cutoff, certain of the guidance constraints will be dropped 
shortly before cutoff. In particular, the position constraints, and the lat- 
eral and vertical position rate constraints are 'dropped as the time-to-go 
approaches zero. The component velocity- to-be-gained constraints are main- 
tained slightly longer and the commands "frozen" just before cutoff to ensure 
zero angular rates and a stable vehicle. The time of cutoff is computed as a 
function of total velocity- to-be-gained and the cutoff command issued to the 
IUS at the proper time. The primary constraints on the orbit are inclination 
and longitude of descending node. The constrained insertion conditions are 
radius, path angle, and velocity.. 

9. 5.4. 2. 2 Orbital Navigation and Guidance 

Orbital navigation and guidance requirements are relatively simple when com- 
pared to boost requirements. Orbital navigation consists primarily of inte- 
grating the orbital equations of motion. The required gravitational model is 
constructed by adding the third and fourth zonal harmonics to the model used 
during boost. 

The only external force of consequence acting on the vehicle and tending to 
alter its orbit is drag. A mathematical model of drag force is used instead 
of using the inertial platform sensors. Therefore, pre-stored equations are 
used in the computation of vehicle drag accelerations. 

If navigation errors are large enough to require correction, the navigation 
state vectors may be updated by ground command. The new state vectors and 

time are transmitted to the flight program via the command system. 

Orbital guidance consists primarily of following a pre -determined attitude time- 
line. In addition, variations to the timeline may be made from the ground via 
the digital command system. 

Attitude Control 


The primary stabilization loop of the IUS vehicle is the attitude control loop 
which is closed by the flight program in the Central Computer. The control law 
requires vehicle turning rates and accelerations and commanded and actual ve- 
hicle attitudes, with respect to the prescribed reference frame, as inputs. 
Attitude error commands are issued to the engine actuators through the vehicle 
control system to effect the control function. 

Limits are applied to the rate of change of the commanded attitude, the commanded 
attitude error magnitude, and the rate at which the commanded attitude error may 
change. Vehicle angular rates are thereby maintained within safe limits. The 
control function is required throughout the mission although the frequency of 
control computations is higher during boost- than during orbit. 
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During the boost period, when control is provided by the main engine, signifi- 
cant control authority with relatively fast vehicle response is available. 
Therefore, a high iteration rate for the control computations is required. 

During the orbital phase, control is maintained by a reaction jet system with 
limited control authority. Thus since the response of this system is slow, a 
relatively slow iteration rate for control computations is adequate. 

Sequencing 

The flight program functional requirements include sequencing of the discrete 
vehicle events. A limited number of discrete sequencing requirements are sat- 
isfied by use of the discrete outputs of the Central Computer. The flight pro- 
gram itself must sequence into the different phases in response to interrupts 
and discrete inputs from the vehicle. These vehicle interrupts and discrete 
inputs signal the occurrence of specific mission events. 

The vehicle sequencing requirements are based on the occurrence of specific 
mission events. Therefore, the vehicle sequencing requirements are divided in- 
to several distinct series of commands. Each series is referenced to a speci- 
fied event. In this manner, vehicle sequencing is correct in spite of pertur- 
bations during previous mission phases. 

Tel emetry 

Data are required from the flight program during its operation for real time 
monitoring of guidance system performance and for detailed post flight evalu- 
ation. Real time data generally consists of the state vector, error or backup 
indications, vehicle attitude, and program/ vehicle status, mode, sequencing, 
and timing information. Detailed data generally consist of intermediate guid- 
ance calculations and hardware information. These data are transmitted to the 
ground stations through the IUS telemetry system. 

Command Processing 

The Digital Command System (DCS) provides the capability to alter certain speci- 
fied flight program functions and data upon receipt by the flight program of the 
proper commands and data from the ground. Some commands will require only a 
valid mode command for execution while others, such as Navigation .Update, re- 
quire a valid mode command and appropriate data for execution. Through use of 
■ the- .command capability, several preplanned alternate modes can be entered or 
corrections can be made for certain predefined off-nominal performance situa- 
tions or vehicle failures through the update and generalized sequencing commands. 

The flight program first validates the mode and data sequence upon receipt of 
the command. Appropriate data are telemetered to the ground to indicate accept- 
ance and validation of the command. If any of several non-allowable conditions 
exist upon receipt of a command; such as invalid command, out of sequence mode 
or data, or valid command at a wrong time; the flight program transmits -the 
proper error message to the ground to inform flight controllers of the conditions 
so that appropriate action may be taken. 

With the exception of the Targeting Load command and the other commands required 
to support it, the command capability is only required during the coast phase 
of the mission. 

Table 9. 5. 4-1 presents the IUS Flight Software size and complexity summary. 
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Table 9.5.4- 1. Expendable I US Flight Software Sizing Summary 


FUNCTION 


INSTRUCTIONS 

(WORDS) 

DATA 

(WORDS) 

COMPLEXITY 

EXECUTIVE 

• 

TASK MANAGEMENT 

225 

345 

.1 

9 

INTERRUPT PROCESSING 

120 

50 

.1 

• 

DISCRETE PROCESSING 

45 

26 

.1 

0 

TIMEKEEPING 

94 

45 

.3 

c 

I/O CONTROL 

100 

650 

.3 

e 

INITIALIZATION/TERMINATION 

900 

83 

.2 

e 

MATH UTILITIES 

864 

— 

.3 

e 

COMMAND DATA POOL 

— 

1200 

— 

NAVIGATION 

e NAVIGATION EXECUTIVE 

125 

45 

.8 

• 

BOOST NAVIGATION 

178 

69 

.8 

• 

COAST NAVIGATION 

1238 

192 

.5 

s 

NAVIGATION UPDATE 

591 

282 

.4 

6 

IMU ALIGNMENT 

2452 

822 

.4 

• 

NAVIGATION UTILITIES 

578 

125 

.3 

GUIDANCE 

9 

GUIDANCE EXECUTIVE 

83 

38 

.8 

9 

BURN TERMINAL GUIDANCE 

105 

37 

.5 

• 

COAST GUIDANCE 

254 

53 

- .75 

0 

BURN GUIDANCE (IGM) 

1645 

280 

.25 

ATTITUDE i 

« 

CONTROL 

INITIALIZATION 

64 

30 

.75 

0 

UPDATE ATTITUDE 

15 • 

3 

.9 

• 

COMPUTE, TRANSFORM ERRORS 

43 

11 

.9 

• 

BURN CONTROL LAW 

233 

32 

.5 

e 

COAST CONTROL LAW 

64 

23 

.6 

9 

CONTROL OUTPUTS 

106 

' 23 

1.0 

SEQUENCING 

t NORMAL COMMAND ISSUANCE 

224 

21 

.6 

9 

ERROR PROCESSING 

195 

28 

.4 

9 

NOMINAL PROCESSING TABLE 

51 

9 

.4 

9 

ALTERNATE TABLE PROCESSING 

47 

11 

.4 

G 

DATA TABLES 

— 

1000 

— 

TELEMETRY 

0 

BLOCK MAINTENANCE 

169 

30 

.5 

0 

RECORDER CONTROL 

161 

34 

.75 

9 

STATION VECTORS (10) 

— 

30 

— 


ORIGINAL PAGTp to 

0F POOR quJS* 
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Table 9. 5. 4-1. Expendable IUS Flight Software Sizing Summary ( Continued) 



INSTRUCTIONS 

- DATA 


FUNCTION 

(WORDS) 

(WORDS) 

COMPLEXITY 

UPLINK PROCESSING 




t READ INPUT 

211 

34 

.4 

• MESSAGE PROCESSING 

154 

35 

.6 

• MESSAGE ACKNOWLEDGEMENT 

53 

6 

.9 

t ERROR PROCESSOR 

66 

10 

.75 

• DATA OUTPUT 

38 

6 

1.0 

• DATA BUFFER 

— 

100 

— 

t FUNCTION PROCESSING 

1100 

100 

. 25 

IMU PROCESSING 




• READ INPUT DATA 

50 

12 

• 1.0 

• RESOLVE AND CONVERT DATA 

100 

108 

.5 

• BODY-TO-INERTIAL TRANSFORMATION 

50 

9 

.4 

• IMU FAULT DETECTION 

600 

30 

.2 


9.5.5 GROUND DATA SYSTEM 

The Central Computer within the I US control center, through its software, is 
the focal point for the entire mission support operation. The computer must 

support a myriad of capabilities - examples of which are listed below: 

• Mission Program Development and Test 

• System Simulation 

• Scientific Computation 

• Training of Flight Controllers 

t Real-Time Support of IUS Mission 

• Schedule and Control Jobshop Work 

Because of the criticality of the Central Computer to the overall operation, 
it is essential that the computer selected be capable of handling all planned 
functions in an orderly fashion and-also provide sufficient growth capability 
to support changing requirements as the IUS program matures. The growth fac- 
tor is particularly significant in view of the fact that the RTCC software 
required for support of the Apollo Program expanded by approximately -50 per- 
cent during that program. As a result, the Central Computer became marginal, 
in some instances, in its ability to perform the burden of work placed on it. 

9.5.5. 1 Computer Selection Considerations 

The principal driving factors in the selection of a computer system are the. 
memory capacity of the computer and its Central Processing Unit (CPU) capabil- 
ities. Additional factors to be considered are peripheral device capabilities 
and the ability to interface with special devices required in the IUS control, 
center. The following paragraphs discuss the primary factors of memory capacity 
and CPU capabilities as they relate to the IUS control center central computer. 
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9,5.5. 1.1 Memory Capacity 

The total size of the system software required to support the I US Mission is 
864,200 words. However, it is not necessary for the entire program to 
continuously reside in main memory. Through a proper structuring of the 
software system, a significant amount of the program can be placed on 
auxiliary storage devices to be read into main memory when required. This 
technique will reduce the demand for core-resident programs and, therefore, 
reduce the main memory capacity requirements; however, the use of auxiliary 
storage will require significant input/output operations which may affect the 
ability of the system to satisfy response time requirements. 

In selection of the computer, a maximum case main memory requirement must be 
established. Through analysis of the software functional requirements, it 
was determined that the maximum memory utilization case for the IUS control 
center would occur when the executive, vehicle system, and mission profile 
modules of the mission program software were required simultaneously. 

As shown in Table 9.5. 5-1, such a combination of software would require 
approximately 415,497 words of main memory. Vehicle system software consists 
of the downlink processing module and the uplink processing model, which 
collectively require 167,900 words of storage, if all vehicle system soft- 
ware were simultaneously in main memory. Worst case analysis has shown 
that the maximum simultaneous requirement, however, is only 65 percent of 
the total vehicle software. This reduces the actual storage load to 109,135 
words . 

The mission profile module total word requirement is 221,100 words, as shown 
on Table 9. 5. 3-8, of which 34.8 percent is the maximum simultaneous require- 
ment. This adds 76,943 words to the total simultaneous memory requirement. 

The control software consists of the executive system module and the control 
center support module, which collectively require 280,600 words of storage. 
The maximum simultaneous requirement is 81.76 percent of the total control 
software. This adds 229,419 words to the total simultaneous memory require- 
ments . 


Table 9.5. 5-1. Co- Resident Summary Requirements 


FUNCTION 

WORDS 

CONTROL 

229419’ 

VEHICLE SYSTEM 

109135 

MISSION PROFILE 

76943 

TOTAL 

415497 

TOTAL + GROWTH FACTOR 

830994 
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9.5.5. 1.2 CPU Utilization 


CPU capability is defined to be the number of operations a computer can per- 
form within a one second interval. In selection of the central computer, it 
is required that the computer have sufficient computational capability to' 
perform all defined functions within the specified time constraints. As in 
the case of memory capacity, CPU growth capability must also exist for 
additional computational requirements as the I US Program-matures. 

Within the Tug control center, the principal factors which directly affect 
the CPU requirements are: 

• Software execution rates 

• Input/output requirements 

• Response times to user requests 

The determination of CPU execution rates- for a proposed computer system is 
a detailed effort requiring the use of extensive modeling techniques. These 
modeling techniques require a detailed knol wedge of software module content 
and frequency of operation. The preliminary nature of software module 
definition contained in this study precludes the use of such techniques and, 
therefore, an alternate approach was taken. 

The functional similarities between the RTCC, JPL, and IUS/OC requirements 
provide a means whereby an analysis of extending system CPU utilization can 
establish a baseline for CPU requirements. Because the RTCC is a "man rated", 
real-time system, its CPU utilization was selected as an upper bound. A 
minimum bound was established from the JPL operation, which is a non-man 
rated, non-real -time system. 

Control Center Computer execution rates were then assumed to be greater than 
the JPL operation and less than the RTCC. Through comparative statistics, 
it was established that the maximum case CPU utilization would require 20 
percent less than the RTCC maximum. Table 9. 5. 5-2 documents the statistics 
for the subject control centers. 

The 75 percent maximum utilization for the IUS/OC when applied to the 360/75 
Model J, results in a maximum CPU utilization of 3.85 x 106 operations/second 
required of the Control Center central computer. 


Table 9.S.5-2. Control Center^CPU Utilization 


CONTROL CENTER* 

5 

CPU UTILIZATION 



MIN 

MAX 

AVG 

RTCC (APOLLO) 

40 

95 

50 

JPL 

10 

60 

12-15 

IUS/OC (PROJECTED) 

30 

75 

40 

* Computer System IBM 360/75, Model J 
Cycle Time - 195 Nanoseconds, 5.128 

x 106 Operations/Second 
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9.5.5. 1.3 Growth Considerations 

As has been stated previously, growth capability in both memory capacity 
and CPU capability must be considered in computer selection. IBM's previous 
experience on similar ground control centers (RTCC and JPL) indicate that 
growth potential in both areas should be approximately 50 percent to satisfy 
requirements. Failure to provide for this growth can severely restrict the 
ability of the IUS control center to expand with the increasing requirements 
placed upon it. A major objective in selecting the central computer should 
be to provide for orderly growth in capability throughout the lifetime of the 
center. 

9. 5. 5. 2 Candidate Computers and Selection 

As was developed previously, the main memory capacity must be a minimum of 
415,496 words to handle maximum case memory requirements, and the CPU 
capability must provide 3.85 x 10^ operations/second. An additional 100 
percent increase in these capabilities to provide the desired growth capacity 
yields the following characteristics the candidate computers must satisfy: 

• Memory capacity - 830,993 words 

• CPU capability - 7.7 million operations/second 

The candidate computers, within the IBM/370 line, which should be considered 
for the ground control center application with the growth capability provided, 
are shown in Table 9. 5. 5-3. 


Table 9.S.5-3. Candidate Computers 


THE LIST 

OF CANDIDATE COMPUTER SYSTEMS (IN ASCENDING ORDER OF INSTALLED COST) 

MEETING OR EXCEEDING THE MAIN 

MEMORY AND 

CPU CRITERIA IS: 





INSTALLED 

YEARLY 

REQ'D 

MEMORY 

CPU SPEED 


SYSTEM 

MODEL 

COST 

MAINTENANCE 

AREA 

(MEGA WORDS) 

(MEGA OPS/SEC) 

1 

3158 

MP6 

6711376 

138795 

3024 


8.70 

2 

3168 

MP4 

10317601 

281730 

3024 

1.05 

12.50 

3 

3168 

MP5 

10931201 

291071 

3024 

1.31 

12.50 

4 

3168 

MP6 

11437201 

295408 

3024 

1.57 

12.50 

5 

3168 

MP7 

11943201 ■ 

299745 

3024 

1.84 

12.50 

6 

3168 

MP8 

12449201 

204081 

3024 

2.10 

12.50 


From the preliminary analysis conducted in this study, the 370/158-MP6 appears 
to be the minimum cost computer which provides the desired growth potential. 

Prior to actual selection of a computer for the ground control center for the 
IUS missions, an extensive modeling study should be conducted. This study 
should utilize the system requirements and software definition and develop a 
detailed model of the control center computer system. From this model, 
detailed statistics can be gathered regarding such items as main memory 
requirements, CPU utilization, auxiliary storage utilization, and system 
response times. All of these data can then be utilized to determine the 
most cost-effective computer system for the control center. 
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9.6 PHYSICAL PLANT 

It has been assumed for the purposes of this study that no existing facilities 
will be utilized. This requires that a separate physical plant be designed 
to house the flight control, flight support, data system, and staff equip- 
ment areas required to support the operation functions. 

The only variable which controls a portion of the physical plant design is 
the number of consoles required by the flight control personnel and the 
flight support personnel. This parameter varies as a function of the opera- 
tional philosophy and data display requirements. 

Figure 9. 6. 0-1 presents a representative floor plan for a, typical concrete 
block, slab foundation structure, 114 feet by 90 feet, to house the flight 
control functions. It is assumed that the government will contract the 
construction of the physical plant and therefore, cost to the government will 
be in two phases: (1) those costs involved in administering and overseeing 

the contract during the period of its execution .and (2) the procurement cost 
of the completed building. 

Procurement costs are estimated on the following basis: 

Raised floor construction - areas requiring subfloor cabling, air 
conditioning, etc,., will cost $50.00 per square foot to construct. 

Ordinary floor construction cost $35.00 per square foot to construct. 

Figure 9. 6.0-1 depicts a representative floor plan with sufficient capacity 
for the personnel and equipment specified in this study. Total area for this 
particular IUS/OC layout is 9,936 square feet of which the following alloca- 
tion of space is tabularized in Table 9. 6. 0-1. 

Table 9.6.0- 1. IUS/OC Area Space Allocation 


TCC AREA 

SQUARE FEET 

Flight Control Room 

1100 

Viewing Room 

243 

Flight Support Room 

600 

Computer Support Area 

594 

Tape Storage 

255 

Office, Restrooms, Canteen 

1080 

Technical Support Area 

1296 

Mechanical Support Area 

612 

Data System Area 

3024 

Hall /Lobby 

1132 

TOTAL 

9936 


The prime considerations in developing this configuration were separation of 
functions, equipment. space requirements, and operations staff positions 
locations. 
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Space allocation for display consoles in the Flight Control Roomand Flight 
Support Room are based on a standard 6x4 foot console with a six foot 
separation between console rows for chair, bookcase and passage. Console 
arrangement is based on operational function and console operator duty. This 
orderly arrangement of consoles groups teams with similar responsibilities and 
consoles with supervisory and summary displays. This provides efficient 
mission support during high and low mission phase activity. It is of partic- 
ular significance during low activity phases where manning is minimal. 
Operational positions that are manned are adjacent permitting efficient 
monitoring all of active IUS vehicle systems during this period. Consoles 
in the Flight Control and Support Rooms face the Technical Support Area. 

This arrangement accommodates the utilization of special large screen displays 
should this be desired. The space allocated in the Data Systems Area is 
comparable to current space requirements for all equipment associated with 
a dual IBM System 370/158* 

9.7 COST ESTIMATES 

The two key elements to the IUS costing methodology are the involvement matrix 
and the cost analysis programs. The IUS involvement matrix is constructed 
by utilizing the Space Tug involvement matrices as a baseline and subtracting 
from the matrix those functions and elements which are not relevant to the 
IUS mission model or support configuration. 

Two involvement matrices were prepared on the Space Tug program, one for the 
Level II autonomy interactions and the other for Level III autonomy. In the 
IUS program, no concise definition of autonomy is available; and, at the 
time the study was first entered, the Reusable IUS and the Expendable IUS 
were competing concepts. 

In order to accommodate the Reusable and Expendable IUS configurations and to 
provide a spread between the higher and lower levels of autonomy, four involve- 
ment matrices were prepared. Level A autonomy is analogous to Level II 
autonomy in the Space Tug, Level B autonomy is analogous to Level III autonomy 
in Space Tug. Mission functions and sub-functions were necessarily different 
not only from Space Tug but between the Expendable and Reusable versions of 
the IUS. However, it was found possible to adjust the two basic Space Tug 
involvement matrices to accommodate Expendable and Reusable IUS cases operating 
at Level A and Level B autonomy. The involvement matrices thus established 
formed a relationship between IUS missions and the support required by the _ 

IUS missions. These matrices were then used as a data base for investigating 
these relationships. 

The major output from the involvement matrices are support requirements. This 
is a summary of the impact the mission structure has upon the ground support 
structure. 

In parallel with the manipulation of the involvement matrices, reference 
missions were constructed by sequencing mission modules into modular time- 
lines. These modular timelines are utilized in the cost analysis programs 
to establish shift density, overlap of modules and overlap of missions when 
compared to the associated traffic model in the cost analysis programs. The 
cost analysis programs accepts inputs from the traffic model , support 


9-68 



requirements, and the modular timelines, then produce a detail printout of 
DDT&E expenses and recurring cost expenses. Figure 9. 7.0-1 illustrates 
the IUS methodology. 

9.7.1 Involvement Matrix 

The involvement matrix is a 277 row by 137 column matrix which defines the 
involvement of the operational elements with the operational functions in the 
covering set of mission operations requirements. The involvement matrix 
provides a method of quantifying the effects of variations in support 
technique and variations in mission operations functions. The difference, 
between the number of relations involved in Level A autonomy support and in 
Level B autonomy support provides a direct process of quantifying the support 
element requirements. The involvement matrices for the IUS were derived from 
the involvement matrices constructed for Space Tug by "zeroing" those support 
elements and mission functions (columns and rows) which are not relevant to 
the IUS design or covering set of mission requirements. Figure 9. 7. 1-1 
presents the involvement matrix. The 137 operational elements are listed 
across the top of the matrix. The 277 mission operational functions and sub- 
functions are listed vertically. 

9.7. 1.1 Autonomy Level Differential 

Figure 9.7. 1-2 shows a typical set of Involvement Matrices; one for Level B ^ 
autonomy, one for Level A autonomy; with the involvements indicated by a "1" 
entry in the matrix cells and no involvement by a "0" in the matrix cells. 

By analysis of the differences in involvement, the support requirements may 
be ascertained. It will be noted that the involvement matrix is merely a 
convenient organization tool for the exploration of inter-related factors. 

The validity of the matrix lies in the effort expended by knowledgeable 
flight control systems engineers in analyzing the operations. 

9. 7. 1.2 Autonomy Level Differentiation Example 

Figure 9.7. 1-3 highlights one line of entries for control center involvement. 
That line is relative to the initialization of guidance, navigation and con- 
trol systems and the alignment of the inertial measuring unit prior to a 
main stage burn. It will be noted that there are four differences (additions) 
between Level A and Level B implementations. Those four differences are: 
in the requirement for 1) command process, 2) command generation, 3) command 
validation, and 4) data transfer outside the IUS operations center. All of 
the foregoing are required to provide a ground command interface with the IUS 
vehicle. The significance in that partial row (Level A) is that the onboard 
system is not entirely responsible for functions required to initialize the 
Guidance, navigation and control system and can thus rely upon the ground 
for some level of assistance in accomplishing those funcions. In turn, flight 
software may be reduced, at the expense of increasing ground software and 
ground manning requirements. Costs can then be associated with each of the 
two related functions and the cost optimal implementation selected. 

9.7. 1.3 Cost Analysis Programs 

Fifteen cost analysis programs have been used to investigate various aspects 
of the support element cost. Figure 9.7. 1-4 presents the flow of logic as 
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Figure 9. 7. 0- 1. /US Methodology 
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Figure 9.7. 1-1. /US Involvement Matrix 
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Figure 9.7.1 -3. Autonomy Level Differentation 
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Figure 9.7. 14. Cost Analysis Programs 
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implemented in the analytical software which creates the total development 
costs and total recurring costs for an operational concept'. The inputs to 
and the outputs from the operations are illustrated. The software active 
during the various processes are displayed by their mnemonic designators 
placed in the elliptical bubbles near the .operations. Cost output information, 
that is, printouts available of the programs, are enclosed in rectangular 
boxes with either the letter D or the letter R entered in the box, indicating 
the final utilization of the derived cost in either the DDT&E summation or 
the recurring cost summation, or both. A sixteenth program, which analyzes 
the alternate concepts of mission operations, was utilized in the generation 
of prior study results. 

9.7.2 DDT&E Costs - Level B EIUS 

First estimates of DDT&E costs have been derived for the Level B EIUS, by 
using the cost analysis programs presented in a previous section. These 
estimates encompass all "deliverable" end items in the EIUS program, but do 
not contain cost elements which have intermediate, or planning type outputs. 

The cost analysis programs account for 90% of the DDT&E expenses. A detailed 
examination of the Work Breakdown Structure (WBS) presented in Volume V will 
identify the elements not priced by the cost analysis programs. 

Figure 9. 7. 2-1 presents the Ground Software DDT&E cost estimate. 

Figure 9. 7. 2-2 presents the Flight Software DDT&E cost estimate 

for the flight software. 

Figure 9. 7. 2-3 presents the Data System DDT&E costs. 

The operational console hardware is tabulated in Table 9. 7. 2-1. 

Figure 9. 7. 2-4 represents the physical plant DDT&E costs. 


Table 9 .7. 2-1. Consoles and Hardware Costs 


Equipment Item 

Quantity 

Unit Cost 

Total Cost 

Console 

17 

4,800 

81,600 

Communication Panel 

28 

6,000 

168,000 

TV Monitor 

34 

2,000 

68,000 

Event Monitor 

66 

8,000 

528,000 

MED 

18 

6,400 

115,200 

Command Panel 

8 

7,200 

57,600 

Display Control Panel 

17 

2,000 

34,000 ' 

TOTAL 



1,052,400 


Table 9. 7. 2-2 summarizes the total DDT&E costs output by the cost analysis 
programs. 
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1 ) WORKING DAYS /MONTHS = 21 

2 ) COMPUTER WORDS /INSTRUCTION = 1 

3 ) PROGRAMMER PRODUCTIVITY (INST. LINES /DAY) =14 

4 ) COMPUTER WORDS /DATA = 4 

5 ) PROGRAMMER PRODUCTIVITY (DATA LINES /DAY) = 30 



INSTRUCTION 

INSTRUCTION 

DATA 

DATA 




SIZE 

COST 

SIZE 

COST 

' COMPLEXITY 

TOTAL 

PROGRAM 

(WORDS) 

(DOLLARS) 

(WORDS) 

(D) 

FACTOR 

(D) 

DOWNLINK PROCESSING 

82800 

1126531 

21900 

34762 

1.00 

1161293 

UPLINK PROCESSING 

38800 

527891 

24400 

38730 

1.00 

566621 

MISSION PROFILE 

142100 

2577778 

79000 

' 125397 

.75 

2703175 

EXECUTIVE 

222000 

6040816 

33300 

52857 

.50 

6093673 

CONTROL CENTER SUPPORT 

13800 

375510 

5200 

8254 

.50 

383764 

DATA COMMUNICATIONS 

3800 

103401 

2500 

3968 

.50 

107370 

SIMULATION SYSTEM 

132200 

2398186 

62400 

99048 

.75 

2497234 

TOTALS 


13150113 


363016 


13513129 


Figure 9.7.2-1. Ground Software DDT&E Costs 







THE CONSTANTS USED IN COMPUTING FIT SFTWB COSTS BY 
THIS FUNCTION ARE : 

1 ) WORKING DAYS /MONTH =21 

2 ) COMPUTER WORDS /INSTRUCTION = 1 

3 ) PROGRAMMER PRODUCTIVITY (INST. LINES /DAY) = 6.9 

4 ) COMPUTER WORDS /DATA = 4 

5 ) PROGRAMMER PRODUCTIVITY (DATA LINES /DAY) =30 



INSTRUCTION 

INSTRUCTION 

DATA 

DATA 



SIZE 

COST 

SIZE 

COST 

TOTAL 

PROGRAM 

(WORDS) 

(DOLLARS) 

(WORDS) 

(D) 

(D) 

DOWNLINK PROCESSING 

330 

34632 

94 

339 

34971 

UPLINK PROCESSING 

1622 

336446 

291 

1049 

337495 

EXECUTIVE 

2348 

728572 

2399 

8644 

737216 

SEQUENCING 

517 

69296 

1069 

3852 

73148 

GUID. ,NAV. AND CNTL . 

8574 

1538354 

2224 

8013 

1546367 

TOTALS 


2707300 


21896 

2729197 


Figure 9. 7.2-2. Flight Software DDT&E Costs 
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6711376 

44560 

20900 
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230000 
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Figure 9. 7.2-3. IUS/0C Support Hardware DDT&E Costs 











IDS OC AREA 


FLIGHT CONTROL ROOM 
FLIGHT SUPPORT ROOM 
DATA SYSTEM AREA 
VIEWING ROOM 
COMPUTER SUPPORT AREA 
TAPE STORAGE 

OFFICES , RESTROOMS , CANTEEN 
TECHNICAL SUPPORT AREA 
MECHANICAL SUPPORT AREA 
HALL/LOBBY 

TOTAL 


SQ . 
' FT. 

D/SQ. 

FT. 

COST 
( D ) 

1100 

50 

55000 

600 

50 

30000 

3024 

50 

151200 

243 

28 

8505 

594 

28 

20790 

255 

28 

8925 

1080 

28 

37800 

1296 

28 

45360 

612 

28 

21420 

1132 

28 

39620 

9936 


418620 


ENTER THE AREAS (IN SQ. FT. 
VIEWING ROOM 
0 : 

243 

COMPUTER SUPPORT AREA 
□ : 

594 


TAPE STORAGE MECH. SUPPORT AREA 

□ : 

.255 612 

OFFICES-, RESTROOMS, CANTEEN HALL /LOBBY 
□ : 0 : 

1080 1132 

TECH. SUPPORT AREA 

□ : 

1296 


Figure 9.72-4. Physical Plant DD T&E Costs 
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Table 9 J 2-2. Total E IUS DDT&E Cost Summery 


Element 

Dollars 

Physical Plant 

418,620 

IUS/0C Software Development 

13,513,129 

Data System 

7,010,008 

Operations Staff Equipment 

1,052,400 

IUS Software Development 

2,729,197 

TOTAL 

24,723,354 


9.7.3 Recurring Costs - Level BIUS 

The recurring costs incurred in orbital operations and mission support are in 
the main service type costs, since there are no major hardware refurbishments 
involved. The types of costs included are: facility maintenance, ground 

software update and maintenance, data system maintenance, IUS flight software 
maintenance, sustaining facilities engineering, sustaining flight control 
engineering and network rental expenses. Of these tasks, facility maintenance 
and data system maintenance will be contracted to outside agencies. Ground 
software update and maintenance will be accomplished by the permanently assigned 
software support team. The sustaining facilities engineering and sustaining 
flight control engineering personnel will perform all pre-mission preparations, 
training and conduct of mission operations. Network rental will be charged 
to the Operations organization on the basis of the number of hours utilized 
and the type of service rendered. The IUS flight software maintenance tasks 
are those tasks involved in defining, programming and verifying mission 
specific deviations from the basic four flight programs. This is largely a 
manpower expense. Computer time will be provided by the control center computer 
at no cost. 

9. 7. 3.1 Facility Maintenance 

Facility maintenance includes refuse disposal, janitorial services, internal 
electrical maintenance, internal power and heating maintenance, internal 
painting, air-conditioning costs, exterior painting, roofing, and parking 
lot maintenance. Facility maintenance costs commonly are based upon a constant 
of approximately $1.32 for government installations and $2.00 for industrial 
installations. The cost of facility maintenance is computed from the estimated 
number of square feet required by the operations and support areas multiplied 
by $2.00 per square foot. This expense is approximately $20,000 per year. 

9. 7. 3. 2 Ground Software Update and Maintenance 

The approach chosen to develop this algorithm divides the software maintenance 
task into two subtasks. The first subtask consists of finding and fixing 
software problems, supporting system operation, and installing nominal mission- 
to-mission program enhancements. The second subtask consists of adding new 
functions and performing major modifications to the existing software system. 

/ 

The cost of the former can best be sized as a "level of effort" task. Since 
software problems will probably be discovered throughout the software system. 
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a level of expertise must be maintained through the availability of personnel 
familiar with every software area. The number of personnel required for each 
area is dependent on the size, complexity, criticality, and level of mission- 
to-mission changes for the programs therein. 

The level of effort will decrease as a function of time. Saturn Launch 
Computer Complex data indicates that the number of software problems decreased 
by more then 50% during the first year of system operation. After the first 
year, the number of problems should continue to decrease but at a much slower 
rate . 

The cost of the second subtask is similar to that of new software development. 
Two offsetting attributes of modification/extension work affect this cost. 

The first is that adding new functions to an existing working system is easier 
than new work due to the existence of well defined, operational interfaces and 
system services. The second attribute applies to modifications. 

Modifications usually require a significantly greater degree of design and 
system testing than the number of instructions involved would indicate. 
Modifications in inter-program interfaces can spread through larger parts of 
the system causing subtle problems which require extensive system testing. 

Given these offsetting factors and assuming a reasonable mixture of the two, 
we can approximate these costs by using the same cost algorithm as used for 
new development work. 

9. 7. 3. 3 Data System Maintenance 

Standard rate schedules exist for the maintenance of large-scale computer 
systems and the associated peripheral gear. For the data systems chosen, 
the data system maintenance costs are approximately $139,000 per year for the 
IDS program. Maintenance of all other equipment will be a responsibility of 
the sustaining flight support engineering organization.- 

9. 7. 3. 4 Sustaining IUS/0C Engineering 

A certain minimum staff is required to control and support the control of an 
IUS vehicle. That staff is divided into two major groupings— the flight support 
group (Sustaining Engineering) and the flight control group. There are 30 
personnel required to staff the flight support organization on a continuing 
basis. These people have been costed at $48,000 per man per year. 

The size of the staff is established by the real-time support requirements. 
However, the staff, during non-mission and non-training periods, is to be 
utilized to perform mission preparations and maintenance jobs. This multiplex- 
ing of personnel is cost-effecitve in that it spreads the productive work load 
of the permanently assigned personnel more evenly across the operational 
periods. 


9. 7. 3. 5 Sustaining Flight Control Engineering 

There is a specific minimum staff required to control the IUS vehicle during 
mission operational periods. For the IUS program, that staff requirement is 
30 flight control engineers. The flight control organization is a required 
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sustaining engineering staff which may be utilized during non-mission periods 
in performing preparation tasks, such as training, scheduling, and interface 
type operations. As with the flight support staff, the spreading of effort 
across the period of operations is a cost-effective utilization of the flight 
control staff. 

9. 7. 3. 6 Network Rental 

In order to arrive at a minimum network rental cost, Phil co-Ford designed a 
system for the transmission of telemetry, command, tracking and television 
data from six STDN remote sites to the IUS operations control center. This 
network utilized commercial carrier satelite transmission directly from the 
ground station to the operations control center. Figure 9.7. 3-1 presents 
the network and terminal cost data derived by Philco-Ford. 

To implement the network, each of the remote stations requires a line terminal 
installation, which creates a recurrring cost of $31,700 per month. The line 
terminal equipment at the remote stations feed commercially available common 
carrier single-sideband data links at a composite leased cost of $284,830 
per month. The leased lines are- demultiplexed at the operations center by 
three line-terminal stations. 

It is assumed that no costs will be incurred to rent the ground station equip- 
ment itself; that is, the data being fed to the line terminals at the STND 
sites are supplied free of charge to the IUS program by GSFC. It is also 
assumed that the terminal stations within the operations center are costed 
as a portion of the network terminal fees and are not part of the network 
rental computation. The summation of the recurring costs of network leasing 
per month and the STDN site stations per month are $475,030. To arrive at 
a minimum cost, the operation of the TDRS system was assumed. This reduced 
the monthly cost of ground station terminal equipment from $190,200 to $31,700. 
This was arrived at by assuming the TDRS ground station would ^provided with 
the terminal equipment and a fee' equivalent to the leased line cost from the 
6 STDN stations would be imposed. 

The summation of a single-station line terminal installation and the leased 
line costs is $316,530. Since these are leased costs, it is assumed that, 
the hourly cost would be equivalent to dividing the summation of leased line 
cost and ground station recurring cost by the number of hours of operation in 
a month. This gives an -hourly rate of $430. Now, the network rental charges 
will be further based upon the type of service required, since all phases of 
the missions do not require the entire capability of the leased lines. A 
further division of the $430 per hour fee was made on the basis of bandwidth 
requirements. The television signal requires 51 kilobits per second, the 
telemetry signals require 16 kilobits per second, the tracking and command 
signals require 2 kilobits per second each. It was estimated that if a. charge 
were made on the basis of service provided, that charge would be approximately 
proportional to the bandwidth requirements of the type of signal being pro- 
cessed. On that basis, television was rated at $290 per hour, telemetry was 
rated at $90 per hour, and command and tracking were each rated at $25 per 
hour. Those constants were utilized in arriving at the network rental 
calculations. 
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COMMON CARRIER 


STDN SITE 

60-108 KHzLSB. 

IUS/OCSITE 

(6 STATIONS) 

(LEASED) 

(3 STATIONS) 

$190,200 

$284,830/MO 

$234,000 


STATION DESIGN AND DEVELOPMENT COST $215,000 


Figure 9.7.3-1. Network and Terminal Cost Data 


The mission density function program within the cost analysis programs cal- 
culates the number of hours per year that each of the communications services 
are required, based upon the launch schedule and mission type established for 
that year. The baseline year chosen for IUS was 1983, 

9. 7.3. 7 IUS Software Maintenance 

A maintenance and support cost algorithm has been developed for flight soft- 
ware. This algorithm assumes that the four baseline programs generated in the 
DDT&E phase will not be subject to major modifications. A major modification, 
should one be required, is to be costed in accordance with the initial 
software development algorithm. 
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The maintenance and support cost algorithm divides the level of effort 
requirements into manpower required to design the changes, manpower required 
to program the changes, and manpower required for flight program verification. 

For programs less than 64,000 words (instructions and data) the level of 
effort is a function of the number of programs being maintained. The annual 
recurring cost for this service is $1,008 million per year for both the IUS 
flight program maintenance efforts. 

9. 7. 3. 8 Off-Peak Manpower Utilization 

Flight control and flight support are full-time employment for- those personnel 
assigned flight control and flight support duties. There will be no multi- 
plexing between operational and non-operational assignments. The time during 
which operations are not in progress will be utilized by the assigned flight 
control and flight support personnel in preparation, maintenance and other 
operations related activities. The frequency and complexity of Space Tug missions 
dictate the assignment of a dedicated staff. 

9. 7. 3. 9 Summary of Recurring Costs 

Table 9.7. 3-1 presents a summary recurring costs. 


Table 9.7,3-T .Recurring Cost Summary 


Element 

Dollars 

Facility Maintenance 

19,872 

IUS/0C Software Maintenance 

1,200,000 

Data System Maintenance 

138,795 

Sustaining IUS/0C Engineering 

1,440,000 

Sustaining IUS Fit. Control 

1,440,000 

TL. Engineering 
Network Rental 

26,233 

IUS Software Maintenance 

1,008,000 

TOTAL 

5,272,900 


9-84 



9.7.4 Alternative Concepts Cost Data 

Figure 9. 7.4-1 defines the operational concepts analyzed during the study and 
the application of the concepts to the IUS and Space Tug Programs. 

Concept 1, Separate NASA/DoD System, is in accord with the NASA baseline con- 
cept and depicts separate NASA and DoD control center development to satisfy 
their respective requirements. In this concept control center hardware, 
software, manpower and facilities will be the responsibility of each separate 
agency; however, it does not preclude the potential of cost savings through 
the development of similar hardware and software. 

Concept 3, DoD System, defines an IUS unique concept where DoD performs all 
IUS missions for both agency traffic models. NASA activity would be limited 
to the definition of NASA mission requirements, mission planning and post 
flight evaluation/data dissemination. 

9. 7. 4.1 Level A Autonomy - Concept Development Cost Comparison 

Figure 9. 7. 4-2 presents a comparison of NASA and DoD expenses for a Level A 
autonomy IUS design under the concepts: 

1) Separate and equal NASA and DoD operation 

3) Single facility, DoD owned, NASA tenant 

Similarity of Concept 1 costs derives from the assumption that NASA and DoD 
operate in similar modes, and the DoD costs are comparable to NASA costs for 
similar functions. 

The shift in costs to increase the host's net outlay in Concept 3 does not 
preclude recovery of some portion from the tenant, but does assume the host 
will retain all program assets. 

The costs presented update and supercede the figures presented in the December 
IUS Baseline Operations Plan (IBM No. 74W-00283). Cost increases in opera- 
tional hardware and flight software have been included. 

9. 7. 4. 2 Level A Autonomy - Concept Annual Recurring Cost Comparison 

Figure 9. 7.4-3 presents a comparison of NASA and DoD expenses for a Level A 
autonomy IUS design under the concepts: 

1) Separate and equal NASA and DoD operation 

3) Single facility, DoD owned, NASA tenant 

Similarity of Concept 1 costs derives from the assumption that NASA and DoD 
operate in similar modes, and the DoD costs are comparable to NASA costs 
for similar functions. 

The shift in costs to increase the host's net outlay in Concept 3 does not 
preclude recovery of some portion from the tenant, but does assume the host 
will retain all program assets. 
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Figure 9J.4-2. Level A Autonomy Development Cost Summaries 
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Figure 9.7A-3. Level A Concepts Annual Recurring Cost Summaries 




The costs presented update and supercede the figures presented in the December 
IDS Baseline Operations Plan (IBM No. 74W-00382). Cost increases in opera- 
tional hardware and flight software have been included. 

9. 7. 4. 3 Level B Autonomy - Concept Development Cost Comparison 

Figure 9.7;4-4 presents a comparison of NASA arid DdD expenses for a Level B 
autonomy IUS design under the concepts: 

1) Separate and equal NASA and DoD operation 

3) Single facility, DoD owned, NASA tenant 

Similarity o.f Concept 1 costs derives from the assumption that NASA and DoD 
operate in similar modes, and the DoD costs are comparable to NASA costs for 
similar functions. 

The shift in costs to increase the host's net outlay in Concept 3 does not 
preclude recovery of some portion from the tenant, but dbes assume the host 
will retain all program assets. 

The costs presented update and superced'e the figures presented in the’ December 
IUS Baseline Operations Plan (IBM No. 74W-00283). Cost increases in opera- 
tional hardware and software have been included. . 

9. 7. 4. 4 Level B Autonomy - Concept Recurring Cost Comparison 

Figure 9. 7. 4-5 presents a comparison of NASA and DoD expenses for a Level B 
autonomy IUS design under the concepts: 

1) Separate and equal NASA and DoD operation 

3) Single facility, DoD owned,- NASA tenant 

Similarity of Concept 1 cost derives from the assumption that NASA and DoD 
operate in similar modes, and the DoD costs are comparable to NASA costs for 
similar functions. 

The shift .in costs to increase the host's net outlay in Concept 3 does not 
preclude recovery of some portion from the tenant, but does assume the host 
will retain all program assets. 

The cost presented update and supercede the figures presented in the December 
IUS Baseline Operations Plan (IBM Noj 74W-00283). Cost increases in opera- 
tional hardware and flight software have been included. 

9.7.5 Rationale for the Selection of Concept 1 Level B Expendable IUS 

The Expendable version of the IUS was selected over the Reusable version of 
the IUS because the Reusable version was approximated by the Space Tug analy- 
tical cases. This allowed more study effort to be directed toward the 
expendable case. 


9-89 






TOTAL ALTERNATIVE DEVELOPMENT COSTS 

ALTERNATIVE 1 ALTERNATIVE 3 

ELEMENT NASA DW NASA ' D CD 

PHYSICAL PLANT 3 82136 420350 0 S3«iggo 

TOC SOFTWARE DEVELOPMEN T 13513129 13S13129 1072753 16627057 

DATA SYSTEM ' 7010008 7010008 0 10515012 

OPERATIONS STAFF EQUIPMENT 1052 400 11576 40 0 1999560 

TVS SOFTWARE DEVELOPMENT 2729197 2729197 2729197 2729197 

T07A& 246 86870 24 830323 3 801950 32U0S016 


TOTAL ALTERNATIVE DEVELOPMENT COSTS 

*• ALTERNATIVE 1 ALTERNATIVE 3 

ELEMENT NASA DOD NASA D CD, 

PHYSICAL PLANT 3 82136 4203SO 0 534990 

TOC SOFTWARE D EVE LCPMEN T 1460S147 146051 47 1454023 l eiO0747 

D AT A SYSTEM 7010008 701000 8 0 10515012 

OPERATIONS STAFF EQUIPMENT 10 5 2 40 0 115 7 6 4 0 0 1 9 9 9 5 6 0 

IUS SOFTWARE DEVEL CPVEN T 2902487 2902487 2902487 2902 487 

TOTALS 2595217 8 26095632 4356510 34052790 


Figure 9.7.44. Level B Develop Cost Comparison 
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Figure 9. 7.4-5. Level B Recurring Cost Summaries 

















Level B version of the Expendable IUS was chosen because the Level A version 
was unable to meet NASSA placement accuracy constraints within the performance 
envelope and had a command system which was limited to only two on/off commands. 
There was, therefore, no capability for real time alternate mission completion 
or timeline adjustment other than to terminate the mission. The conversion 
from Expendable Level A to Expendable Level B involves the addition of a 
digital command system and the associated interfaces to the onboard computer. 

It was thus possible to achieve the economic advantages of Level A Expendable 
IUS with the operational complexity required by NASA for minimum design 
change and cost. 

Concept 1 was selected because Concept 3 involves NASA tenancy on a DoD 
facility with all of the attendant operational and access difficulties. DoD, 
due to the nature of their mission, must maintain a more rigid security than 
NASA. The probability of successfully operating a joint facility with dis- 
similar security requirements is low. 

The technique used to establish the above conclusions is an adaptation of the 
Kepner-Tregoe Decision Analysis methodology to the parameters of the IUS 
program. 

Six objectives were established. An objective, in Kepner-Tregoe context, is 
a factor or consideration to be optimized. Differing implementations, or 
"Alternatives" have differing impacts upon the objectives. In order to 
quantity these impacts and place the values of the objectives into perspective, 
each objective is given a “Rank", which is a numerical weight between 1 and 
10 establishing the relative importance of the objective. 

The impact of each alternative is established by analysis of the alternative 
and the estimation of the effect on the objective; a number between 0 and 10. 

In assessing the impact of alternatives, the sense of the' assessing is that 
numerical value increases as "desirability" increases. For example, cost is 
an objective which is inversely related to desirability. Thus, higher cost 
results in a lower numerical value. 

Once the impact of each alternative on each objective is established, a 
computer program performs the computations required to establish a final 
relative ranking of the alternatives. 

The process is identical for establishing the undesirable attributes of each 
alternative. The final results are obtained by weighting the finishing order 
of desirable and undesirable alternatives and selecting the best composite 
alternative. 

Three experienced mission operations engineers were given the task of establish- 
ing the impact of the Space Tug alternatives on a fixed set of objectives 
and adverse consequences. Figure 9. 7. 5-1 illustrates the Kepner-Tregoe input 
sheet. 

Table 9.7. 5-1 (a) presents the summary results of the three inputs after 
computation and rank-ordering. 

The first column of Table 9. 7. 5-1 (a) is the weighting factor for rank-order. 
This is used to further drive apart the finishing position of each alternative. 
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IUS CONCEPT TRADE 


INPUT DATA SHEET 



MOD. ABILITY ! 5 

ACCESS 5 - 


ADVERSE 

CONSEQUENCES 

PRE-EMPTION 

HUMAN ERROR 

CHANGE CONTROL 

MOTIVATION 


• INPUT DATA FROM 3 EXPERIENCED ENGINEERS 

• WEIGHTED (+5 TO -5) INDIVIDUAL SELECTIONS 

• NUMERICAL SUM OF FACTORS/CONCEPT 

• SELECTED "BEST SCORE" CANDIDATE 


Figure 9.7.5-1. Kepner-Treqoe Input Sheet 



Table 9. 7. 5-1 (b) is the final weighting matrix. The weighting factor of 
Table 9. 7. 5-1 (a) is multiplied by the number of times the alternative appears 
in the row having a weighting factor of 5, it is given a score of 10 in 
column one of Table 9.7. 5-1 (b)._ When that operation is completed the 
columns are summed to give the final selection. 

The I US alternative scoring highest was expendable Level B autonomy - Concept 
1, with Reusable Level B/Concept 1 ranked second. This leads to the conclusion 
that, based upon the objectives and adverse factors analyzed, expendable 
Level B Autonomy - Concept 1 implementation is the best selection for IUS 
operations. 
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Table 9.7.5-1. Kepner-Tregoe Results 
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POTENTIAL PROBLEM AREAS SUMMARY 


The IBM study defined items which appear to be potential problem areas for IUS 
operations while other-areas require further consideration or analysis. A 
summary of these items are included in this section: 

• IUS Activation Sequence - The timeline inputs from the IUS studies 
indicate that the IUS will be transferred to internal power and the 
communications activated prior to the Orbiter circularization burn. 
The deployment analysis by IBM indicates these subsystems should be 
activated just prior to umbilical disconnection, which is after the 
Orbiter circularization burn. Further analysis of these conflicts 
is needed. 

• IUS Post -Deploy Activation - The IUS timelines indicate the IUS ACS 
is activated approximately 90 seconds after RMS separation. Further 
analysis is required to determine the time from RMS release to ACS 
attitude hold initiation. 

t IUS/TDRS Interface Capability - The present baseline IUS data 
provided by NASA does not include the capability for IUS/TDRS 
communications interface. The NASA requirement exists for the IUS 
to provide the onboard capability for TDRS interface. This should 
be pursued to assure the capability is included on the IUS. 

• STDN/TDRS Support For IUS Missions - In the event the IUS/TDRS 
interface is not feasible, STDN support after IUS deployment from 
the Orbiter is limited, and for some missions, no STDN support is 
available for post-deploy activation or main engine burn phases. 
Without TDRS interface, limited ground support is available for 
IUS critical events. Consideration should be given to performing 
more detailed timeline analyses for a variety of IUS missions. 

• TDRS support for 64 KBPS TM Link - The use of the 64 KBPS IUS 
output requires a single access channel, wherein, use of the 16 KBPS 
requires only a multiple access channel. The requirements for the 
64 KBPS link interface Drior to deployment (when the IUS isr 
attached to the Orbiter) and after deployment should be assessed. 

• ' IUS Checkout - As discussed in Section 6.2, the IUS does not have 

the capability for complete self-checkout. The requirements for 
this capability should be reassessed. 

• Retrieval of a Disabled EIUS - This study did not include the_ 
analysis for retrieval of a disabled EIUS (or Spacecraft) if it is 
in an Orbit which is accessable to the Orbiter. An example would be 
the failure of the EIUS prior to its first mainstage burn. This 
area should be studied to determine if a retrieval capability for 
the EIUS is justified. 


10-1 



• Spacecraft Orbiter Impacts - The EIUS Orbiter software impacts 
were investigated, but the Spacecraft software impacts on the 
Orbiter were not. The Spacecraft impacts should be assessed to 
determine the total EIUS and Spacecraft impacts on the Orbiter. 

• EIUS Deployment Adapter (Cradle) Definition - A dated cradle 
definition was used by IBM for the deployment sequence and opera- 
tions analysis. An updated deployment adapter definition from the 
current DoD studies should be assessed for potential impacts on 
flight and timeline operations. 
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